I recently had a requirement to make security group members be members of a set in FIM. This is not as easy as it sounded. Our requirements were:

– Users should only be able to assign roles to other users that they themselves have.

– Roles translate to security group membership in AD based on criteria-based security groups.

We decided to change the thought process a bit and realized we were only using roles to create security groups. So, why not take roles out all together. The end result works something like this:

1. A new Reference multivalued attribute is on the user called SecurityGroups.
2. This attribute contains the groups the user belongs to.
3. A new Set of Users is created for each security group.
a. The set is a criteria based set where the SecurityGroup attribute of the user contains the security group.
4. A new Set of Groups is created for each security group.
a. This is a criteria based set where the display name is the name of the group.
5. A new MPR is created for each set of users created in step 3 to grant them permission to write to the SecurityGroup attribute on all users.
6. A new MPR is created for each set of groups created in step 4 to grant the set of users created in step 3 read permissions on the set of groups created in step 4.

It needs some workflow automation probably to be feasible, but in theory this allows us to have sets based on group membership.

The PES service needs to be installed on the source domain.

However, it relies on keys generated on the target domain.

So, on the machine running ADMT, execute this command to create the keys:

admt key /option:create /sourcedomain:domain.com /keyfile: peskeys /keypassword: password1

Move the resulting key file to the DC in the source domain.

Download PES from http://www.microsoft.com/en-us/download/details.aspx?id=113070 (x86 version)
or http://www.microsoft.com/en-us/download/details.aspx?id=1838 (x64 version)

Double click the exe file to start the installation. You will need to provide the path for the key file. You will also need to provide a service account. Although you can use the Local System account, if you run it as a domain user from the target domain you can avoid having to add the Everyone group and Anonymous Logon group to the Pre-Windows 2000 Compatible Access group.

1. Open Group Policy Management from Administrative Tools.
2. Expand the tree until you find the domain you are using.
3. Expand the domain tree. (You may have to right click and select “Show domains” to see your domain.)
4. Select “Group Policy Objects”
5. Select “Default Domain Controllers Policy” and choose “Edit”.
6. In the new window that opens, navigate to: Computer Configuration–>Windows Settings–>Security Settings–>Local Policies
7. Select “Audit Account Management” and be sure both “Success” and “Failure” are selected for auditing.

You will have to reboot or wait about 15 minutes for the change to take effect.

During the process of development, we discovered the following requirements for the writing to sidHistory to work.
– The process must run on the destination domain. Although the documentation for clonepr.dll says it must be run from the PDC, we did a test and ran it on a DC that can update sidHistory on other DCs. If running it on a DC, sidHistory is only set on that DC and AD replication should move the sidHistory.

– The process must be run from the same PDC that is referenced in the destination DC of the config file. Otherwise, an “Access is denied” error is returned.

– The process must reference the PDC of the source domain. Otherwise, an error will be reported that “The operation is only allowed for the Primary Domain Controller of the domain.”

– The account running the process must also have a foreign security principal in the source domain.

– The account must be an Administrator on the source domain.

– The account must have read write access to the sidHistory attribute destination domain. (A security group can be created to grant the account this right. In our environment, the account was also an ADMA account.)

– The account must have the “Delegate Control”->”Migrate SID” permission.

– The account change auditing needs to be enabled on both servers. (The document clonepr.doc has instructions on how to accomplish this.)

– The source domain needs a domain local security group called “DomainName” + “$$$”. No members need to be added to this group, but the process does add members to this group while it is migrating the SID and then removes the members from the group.

– The service account needs full control over the OU holding the objects that are having their sidHistory attribute populated.

In a FIM sync, without these settings, I was receiving a “permission-denied” error. These settings were for a separate program to migrate sidHistory.

I’m troubleshooting the error on FIM installation:

“Forefront Identity Manager Synchronization Service is having trouble contacting SQL server using the provided information. Please note that Forefront Identity Manager Synchronization Service requires Microsoft SQL Server 2008 SP1 or better. Verify the version, server and instance names as well as firewall settings and try again.”

The SQL Server is in a different domain and a different forest. There is a two-way trust. (I know one way trusts where SQL doesn’t trust the domain FIM is in don’t work.)

Since I’ve seen this error in the past, I thought I’d write out the steps I’m taking to troubleshoot:

1. Verify an ODBC connection can be made from FIM to SQL.
2. Verify Firewall rules.
3. Enable verbose logging on the installation: msiexec /i [File location] /lv*x [Log file location–file must already exist] (http://msdn.microsoft.com/en-us/library/windows/desktop/aa367988(v=vs.85).aspx) Search for return value 3 to find the error.
4. Disable IESC for Administrators.
5. Verify Full Text Search is installed on SQL.
6. If using a non-default SQL instance, verify the SQL Browser is running.
7. Verify SQL Agent is running.
8. Verify the SQL Native Client is installed on FIM.

In this case, the SQL Native Client was the issue.

I recently was RDP’d into a server and from there had RDP’d to another server.

Using the standard CTL+ALT+END to get to the login screen didn’t work.

I had been connecting by just using the Accesstories–>Remote Desktop Connection and clicking OK since the server was already in the history. This would take me through a credentials box which logged me into the server as it connected.

To fix this, I created a remote desktop connection without any user credentials–just using a value in the Computer of the General tab, but not entering a user. (Click the Options button on the Remote Desktop Connection start screen.) This avoided the Window pop up style login.

I kind of feel like a tool for how elementary this seems now, but figured I’ll either forget it or maybe it’ll help someone in the future.

When working with the AddSidHistory call, I was getting this error. I was stumped as I had followed all of the permissions required for the account running the script. (These are all documented in the clonepr.doc.)

It turns out it was one or possibly two things:

1. For some reason, the delegate control for “Migrate SID” wasn’t on one of the OUs, even though I’d granted it at root level. (Probably a user error there as it was late in the day.)

2. This was a lab environment and I thought I was working off of PDCs, but nope. Turns out there were PDCs hidden from me.

In total, here are the permissions I granted the service account:

– delegate control to migrate SIDs.
– Administrator member on source domain and Domain Admin on target domain.
– Create the target group domainName = “$$$” to hold users having their SIDs migrated. (Don’t put the users in there, the code will do that for you.)
– Granted the service account Full Control over the target OU and Read over the source OU. (This may be overkill…And I’d think adding the user to Domain Admins should do taht anyway, but the client has a complex AD security structure.)
– Enabled the event logging for changes to SIDs via the Account Management option in Local POlicies (clonepr.doc has the steps to do this).
– Ran the script on the target PDC.

Hope that helps someone.

I was getting this error (remote procedure call failed 0x800706BE) when doing a sync on any of the management agents except the FIM MA.

I have custom rules extensions for all of my management agents except FIM MA and they all rely on one Utils.dll I wrote.

It turns out there was an error in one of the methods in the Utils.dll and, because I had turned off my debugging feature, I wasn’t getting any other information about the error. Reverting to an older version of the dll fixed the problem.

I was running into an issue where I had set a host header for a SharePoint site, but was unable to authenticate. I’d get prompted for credentials three times and then receive a 401 error. (The site worked with the computername and ip address.)

This registry change for BackConnectionHostNames fixed the issue for me: http://support.microsoft.com/kb/896861

I need to read up a bit more on what that is actually doing to be sure it’s OK for our needs though.

In a lab environment, I wasn’t able to access the password registration portal from any server other than the FIM portal server. Turns out, I’d missed setting the SPN for the HTTP/Password Registration and Reset portals.

http://social.technet.microsoft.com/wiki/contents/articles/4118.aspx