Vitamins, Painkillers and Viagra (this is not spam)

Dick Hardt has written a interesting, reflective article. Is your product or our consulting service a vitamin, a painkiller or viagra? Read the definitions in http://dickhardt.org/2010/01/vitamins-painkillers-and-viagra/

Using ILM for DMZ Account Management

When you need to manage your users and group in a DMZ, it can be done in several ways. At least these methods can be used -

• Autonomous. All users and groups are maintained locally in the DMZ.
• Forest trust. A forest trust is constructed so the DMZ forest trust internal accounts. To restrict.
• Read-only Domain Controller. A RODC is deployed in the DMZ.

Besides these, ILM can also be used and when you read the advantages/disadvantages below, you may or may not decide that ILM is the best for your environment.

Method	Advantages	Disadvantages
Autonomous	Can be totally isolated No firewall setup No information leak from internal AD	Expensive owing to added administration Distributed administration No SSO
Forest trust	Good integration with internal AD SSO with Kerberos Access to DMZ for internal AD objects can be restricted with Selective authentication	Complex firewall setup Cannot pick internal objects with GUI picker (unless you open for LDAP from non-DC) Have to change the registry to allow RDP logon on WS03. See KB 902336
Read-only domain controller	A single forest SSO Exposure can be controlled by managing what sensitive properties are on the RODC	Windows Server 2008 only Complex control of updates like DDNS Cannot limit users and groups visible
ILM	Simple firewall setup No inbound firewall rules No ILM license if you use IIFP (Enterprise Edition is required). See more below. Single place of management in the internal AD. Everything is pushed to DMZ including password changes. Helpdesk does not need access to DMZ and not even special procedures for changing properties. Full control of what object that are visible in DMZ No leak of other objects (trust cannot be queried) SSO or at least same password	Requires an extra infrastructure component SQL license (unless existing can be used) May not have full SSO to all services (re-enter password)

The seems fine, you say. I know how to do the other stuff, how complex is it to implement the ILM solution? Well, with ILM 2007 you have to create at least some code or get the code from someone who have made it (like Inceptio). But besides this, the rest is standard components. A very rough plan looks like this -

• Install ILM
• Install and configure PCNS on the internal AD domain controllers to capture password changes
• Enable password management in ILM
• Create an DMZ AD management agent, specifying it as password target
• Create an internal AD management agent. Specify it as password source and the DMZ AD Management Agent as target
• Create a management agent that can figure out what objects should be replicated to DMZ (use a group membership, naming convention or some other property). Let this populate an expectedDN property. If the logic is simple, it could be done in an MVExtension. In the solution I have made, I have done it using attribute-value-property files and PowerShell code.
• Flow the properties you want to keep in sync from the internal AD and export them to the DMZ AD

With Forefront Identity Manager (FIM) 2010, you should be able to get rid of the coding part, making the solution more attractive. When it comes to IIFP, that is not supported anymore. Microsoft removed the download at some time but made it available again. From my sources at Microsoft, no IIFP version of FIM will be available, so you have to buy it.

Executing PowerShell code from within your own program

In V2 this got a lot easier. Here’s my PSExecute function. The idea is that you send in a text value and a script. The script references the value as $_. All output from the script is returned as the result of PSExecute. Exceptions (e.g. syntax errors), errors etc. are returned as well. Depending on the usage, this may not be what you need, but you can change it yourself.

I’m planning to use this in combination with ILM. Having the ability to use a piece of PowerShell script in an advanced flow rule or in the MVExtension seems very useful.

A script could be $_.toupper() etc.

private String PSExecute(String Script, String InputValue)
{
    // Create PS outside the function if called multiple times for performance reasons
    PowerShell PS = PowerShell.Create(); 

    // The script could probably be parsed once to speed things up if the same script is used repeatably
    PS.AddScript("'" + InputValue + "' | foreach {" + Script + "}");
    String s = "";
    try
    {
    foreach (PSObject result in PS.Invoke())
    {
        s += result.ToString();
    } // End foreach.
    }
    catch (Exception e)
    {
    s += "EXCEPTION: " + e.Message; // ToString();
    // just continue
    }
    foreach (DebugRecord result in PS.Streams.Debug)
    {
    s += "DEBUG: " + result.ToString();
    }
    foreach (VerboseRecord result in PS.Streams.Verbose)
    {
    s += "VERBOSE: " + result.ToString();
    }
    foreach (WarningRecord result in PS.Streams.Warning)
    {
    s += "WARNING: " + result.ToString();
    }
    foreach (ErrorRecord result in PS.Streams.Error)
    {
    s += "ERROR: " + result.ToString();
    }

    return s;
}

If you want to try it from PowerShell first, here’s the statements -

$script='$input | fforeach {$_.toupper()}'
$script='$_.toupper()'
$ps=[System.Management.Automation.powershell]::create()
$ps.AddScript('''' + $Inputvalue + ''' | foreach {' + $script + '}')
$ps.invoke()
$ps.Streams

Have fun!

ILM “2” will ship in Q1 2010

According to my colleague, Risto Pedersen. He heard it at the keynote at TEC 2009 in Las Vegas.

ILM "2"

MIIS is a great engine for synchronization but the lack of a decent interface - for the administrator as well as for the end user - have made it necessary to either create a lot of code yourself or invest in other systems like Omada.
With ILM "2" (what a nice name...) the game has changed. While not as complete as Omada, ILM "2" seems to have a bunch of very useful features. I just attended an instructor led lab session here in Barcelona and the way and how easy you can do workflows and dynamic groups, makes a pure ILM "2" implementation possible - at least as a starting point or for simpler things. I haven't digged into ILM "2" too deep (yet), but what I have seen, seems ok.

Pull down an VHD with the RC-code from http://technet.microsoft.com/en-us/evalcenter/cc872861.aspx

Server 2008 R2 Active Directory and PowerShell

Filling my head at Tech-Ed, luckily, others are more efficient bloggers than I am.

Read this excellent summary by Dmitry of the "Windows Server 2008 R2 Active Directory: What’s Coming Up"” session at IT Forum (TechEd EMEA IT Pro) by Robert DeLuca and Alain Lissoir