The following call stack was discovered when reviewing the Application Event Log on the Forefront Identity Manager Certificate Management (FIM CM) server. In reviewing this stack trace, we noticed the GetGroupBySid function call. The GetGroupBySid function does a lookup in Active Directory for the group using the ObjectSid of the group. Knowing this, we want to review the FIM CM Web.Config file.
<Data>at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) at System.DirectoryServices.DirectoryEntry.Bind()
at System.DirectoryServices.DirectoryEntry.get_Name()
at Microsoft.Clm.DS.DirEntry.BindDirectoryEntry(ProviderType providerType, String serverOrDomain, String path)
at Microsoft.Clm.DS.User.GetGroupBySid(Sid sidGroup)
at Microsoft.Clm.BusinessLayer.AccessControlManager.LoadGroupSecurityDescriptor(Sid sid)
at Microsoft.Clm.BusinessLayer.AccessControlManager.CheckUserAccess(String principal, DirectoryEntry userEntry, UserAccessRights desiredAccess)
at Microsoft.Clm.BusinessLayer.UserAccess.CheckUserAccessByName(String principal, String userName, UserAccessRights desiredAccess)
at Microsoft.Clm.Web.Security.CanPerformActionOnUser(String userName, ManagementAction action) at Microsoft.Clm.Web.Modules.ActionLinksUserControl.checkActionsByOfflineUnblockPermission()
<!-- PLUGGABLE EXTENSIONS *********************************************-->
<!-- Request Security Implementation Clm.RequestSecurity.Flags Flags used for configuring default implementation. Allowed values are: UseUser UseGroups These values can be OR-ed. If not specified, the value is defaulted to "UseGroups"
Clm.RequestSecurity.Groups
Comma-separated list of AD groups (Global or Universal) that will be used to determine certificate manager access to users that are members of these groups. The list should contain group names using DOMAIN\group format. Leaving the list empty forces CLM to consider all groups that users are members of.
EXAMPLE: <add key="Clm.RequestSecurity.Flags" value="UseUser,UseGroups" /> <add key="Clm.RequestSecurity.Groups" value="DOMAIN1\Group1,DOMAIN2\Group2" />-->
<add key="Clm.RequestSecurity.Flags" value="UseUser,UseGroups" />
<add key="Clm.RequestSecurity.Groups" value="" />
<add key="Clm.RequestSecurity.ManagerCanApprove" value="false" />
*NOTE: Leaving the list, CLM.REQUESTSECURITY.GROUPS empty, forces FIM CM to consider all groups that users are a member of (Yes, we're ending a sentence with a preposition, but that's something we'll have to get over.)
RESOLUTION To resolve this issue, we limited the list of groups to the Clm.RequestSecurity.Groups to those security groups that are of interest to FIM CM. Essentially those configured in the Policy Settings in the FIM CM Portal. Was this a magic fix, guaranteed to work every time you get the "no such object on the server" error? - Of course not!
We never dug into what object wasn't found. To do this we would need to collect more data such as:
Additionally, another possible cause could have been one of the groups we included in the UseGroups flag.
That said, this solution allowed us to get back to business. As an added benefit, taking advantage of the UseGroups setting typically speeds up FIM CM operations; instead of having to iterate through an unknown number of groups to verify user permissions, we are only looking at limited subset of groups.
In conclusion:
Ed Price - MSFT edited Revision 11. Comment: Updated title per UX Guidelines
Ed Price - MSFT edited Revision 10. Comment: Spacing and fonts
Tim Macaulay edited Original. Comment: had to clean up the information