My PowerShell script to fix the ObjectSID on an account in the portal has been posted to the FIM ScriptBox:
There are all sorts of scenarios where I've seen people hobble their implementation and the ObjectSID gets recalled from the Built-In Synchronization Account. Also, in cases where you are using custom workflows you will need to have the credentials for your web service account in the portal and in some cases you may not want to be "managing" your service accounts in the portal. In any case, having a way to hack the ObjectSID back into the portal object is a real lifesaver. In order for most authentication scenarios to succeed against the portal you need to have the object populated with the ObjectSID of the account in AD. During the Authentication process, the FIM Service queries the database for an account with a matching ObjectSID to the person attempting to authenticate through IIS. In other cases, you still need a matching AccountName and Domain value, but to be safe all authenticating accounts should have all three values populated to function in all scenarios.
Clever scripters will be able to modify this script to set any single value on any portal object. Thanks to Joe Schulman and Markus Vilcinskas for prior examples.
Be sure to check out the other excellent scripts in the FIM ScriptBox!
0 comments:
Post a Comment