'ForeignSecurityPrincipal lookups' error and/or 'DirectorySearcher returned no results' under debug in ADUM Logs

  • 16 February 2021
  • 0 replies
  • 10 views

Userlevel 5
Badge +20
 

'ForeignSecurityPrincipal lookups' error and/or 'DirectorySearcher returned no results' under debug in ADUM Logs

kbt127804

PRODUCT
K2 blackpearl
This article was created in response to a support issue logged with K2. The content may include typographical errors and may be revised at any time without notice. This article is not considered official documentation for K2 software and is provided "as is" with no warranties.

Issue

Under unique circumstances (i.e. The machine and user having the same name) the DN passed via managed ad can have issues resolving the user in K2, which can result in loss of group membership, access, etc. This can be easily tested via the force identity refresh tool (http://community.k2.com/t5/General-K2-Utilities/Force-Identity-Service-Refresh/ba-p/74061).

 

Flip ADUM logging to Debug > Check user in identity cache to see if enabled > if enabled fire off the refresh tool for the user > check identity cache again to see if user is still enabled > if not drill into the adum logs.

 

Typically here you would see the 'DirectorySearcher returned no results' flag which means the DN passed did not yield results in AD. You can see the DN and if you drill into AD for the user it is possible that the Distinguished Name would not jive. Typically here there is another AD object that is causing this, i.e. there is a workstation that shares the same name, or some oddball OU configuration, etc.

 

If the user is enabled then the issue stems with a group the user is mapped too. Try to isolate the group, and run through the same iterations as above.

Symptoms

Loss of group membership, permissions, etc.

Resolution

Add 'TranslateWithDirectoryServices=False' to the roleinit; example from fictional denallix box below. This key enables K2 to take a different code path in which the samaccountname is translated via native ad vs managed ad.

An example UPDATE statement is pasted below. This is derived from a denallix box.

 

UPDATE [HostServer].[SecurityLabel]
SET [RoleInit] =
'<roleprovider>
<init>ADCache=0;LDAPPath=LDAP://DC=DENALLIX,DC=COM; TranslateWithDirectoryServices=False;ResolveNestedGroups=False; IgnoreForeignPrincipals=False;IgnoreUserGroups=False;MultiDomain=False; OnlyUseSecurityGroups=False;LogLevel=Error;LogSize=0;DataSources=&lt; DataSources&gt;&lt;DataSource Path="LDAP://DC=DENALLIX,DC=COM" NetBiosName="DENALLIX" /&gt;&lt;/DataSources&gt;;;</init>
  <login />
  <implementation assembly="ADUM, Version=4.0.0.0, Culture=neutral, PublicKeyToken=16a2c5aaaa1b130d" type="ADUM.K2UserManager2" />
  <properties>
    <user>
      <property name="Name" type="System.String" />
      <property name="Description" type="System.String" />
      <property name="Email" type="System.String" />
      <property name="Manager" type="System.String" />
      <property name="SipAccount" type="System.String" />
      <property name="ObjectSID" type="System.String" />
      <property name="DisplayName" type="System.String" />
      <property name="CommonName" type="System.String" />
      <property name="UserPrincipalName" type="System.String" />
    </user>
    <group>
      <property name="Name" type="System.String" />
      <property name="Description" type="System.String" />
      <property name="Email" type="System.String" />
    </group>
  </properties>
</roleprovider>'
WHERE [SecurityLabelName] = 'K2'

 

**ADDING THIS KEY WILL ONLY ALLIVIATE THE ISSUE IN 4.7**
**TROUBLESHOOTING IS APPLICABLE PRE 4.7, BUT SOLUTION IS NOT**

HAVE A GOOD DAY!!!

0 replies

Be the first to reply!

Reply