No able to access user from an AD trusted forest

[Aymen Frikha]

Hello,

I'm trying to add a new keystone domain that will be integrated with an AD but will access users in a trusted forest, not the principal one, I've created the current configuration for the charm:

keystone-ldap-tenant:
  ldap-server: "ldap://xx.xx.xx.xx"
  ldap-user: "CN=xx,OU=xx,DC=intsvc,DC=local"
  ldap-password: "Pass"
  ldap-suffix: "DC=intsvc-test,DC=local"
  ldap-readonly: true
  domain-name: "tenant"
  ldap-config-flags: "{
        user_tree_dn: 'OU=Tenant,DC=intsvc-test,DC=local',
        query_scope: sub,
        user_objectclass: person,
        user_name_attribute: sAMAccountName,
        user_enabled_attribute: userAccountControl,
        user_enabled_mask: 2,
        user_enabled_invert: false,
        user_enabled_default: 512,
        user_allow_create: False,
        user_allow_update: False,
        user_allow_delete: False,
        chase_referrals: True
       }"

But not able to list the users and got this error:

2021-10-20 16:07:42.569089 File "/usr/lib/python3/dist-packages/keystone/identity/backends/ldap/common.py", line 643, in wrapper
2021-10-20 16:07:42.569095 return func(self, conn, *args, **kwargs)
2021-10-20 16:07:42.569106 File "/usr/lib/python3/dist-packages/keystone/identity/backends/ldap/common.py", line 777, in search_s
2021-10-20 16:07:42.569112 return conn.search_s(base, scope, filterstr, attrlist,
2021-10-20 16:07:42.569123 File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 854, in search_s
2021-10-20 16:07:42.569130 return self.search_ext_s(base,scope,filterstr,attrlist,attrsonly,None,None,timeout=self.timeout)
2021-10-20 16:07:42.569141 File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 1266, in search_ext_s
2021-10-20 16:07:42.569147 return self._apply_method_s(SimpleLDAPObject.search_ext_s,*args,**kwargs)
2021-10-20 16:07:42.569158 File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 1204, in _apply_method_s
2021-10-20 16:07:42.569164 return func(self,*args,**kwargs)
2021-10-20 16:07:42.569175 File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 848, in search_ext_s
2021-10-20 16:07:42.569182 return self.result(msgid,all=1,timeout=timeout)[1]
2021-10-20 16:07:42.569193 File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 740, in result
2021-10-20 16:07:42.569199 resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
2021-10-20 16:07:42.569210 File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 744, in result2
2021-10-20 16:07:42.569217 resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all,timeout)
2021-10-20 16:07:42.569228 File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 748, in result3
2021-10-20 16:07:42.569234 resp_type, resp_data, resp_msgid, decoded_resp_ctrls, retoid, retval = self.result4(
2021-10-20 16:07:42.569245 File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 758, in result4
2021-10-20 16:07:42.569251 ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
2021-10-20 16:07:42.569263 File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 331, in _ldap_call
2021-10-20 16:07:42.569269 reraise(exc_type, exc_value, exc_traceback)
2021-10-20 16:07:42.569280 File "/usr/lib/python3/dist-packages/ldap/compat.py", line 44, in reraise
2021-10-20 16:07:42.569286 raise exc_value
2021-10-20 16:07:42.569297 File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 315, in _ldap_call
2021-10-20 16:07:42.569303 result = func(*args,**kwargs)
2021-10-20 16:07:42.569331 ldap.REFERRAL: {'desc': 'Referral', 'errno': 11, 'info': 'Referral:\\nldap://intsvc-test.local/DC=intsvc-test,DC=local'}

[Billy Olsen (billy-olsen)]

You might want to check which ports you are using. In active directory, you may prefer the global catalog ports. See bug https://bugs.launchpad.net/charm-keystone-ldap/+bug/1910293

[Billy Olsen (billy-olsen)]

Can you try with ports for the global catalog?

[Aymen Frikha (aym-frikha)]

@billy yes I tried it, but nothing worked since the users in the trusted forest are listed as foreignsecurityprincipal object in Active directory and they cannot be treated as normal persons and neither listed with keystone. So no, I don't think that this is something that we can support. Users are listed with urls similar to that: LDAP://CN=S-1-5-21-100066778-12312342-412341235-513,CN=ForeignSecurityPrincipals,DC=domain,DC=com"

[Launchpad Janitor (janitor)]

[Expired for OpenStack Keystone LDAP integration because there has been no activity for 60 days.]