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.