Hello,
I need to bind sometimes with a username that is not in DN format. I have tried to use authz-regexp to translate it but I am not successful.
I have created a few entries and I can authenticate with the Manager DN. I can also authenticate with other entries when I explicitly use a DN, but when I use something that does not start with "dn=", it fails.
I have this entry that I want to use for authentication: dn: cn=ServiceAccount@old-domain.com,dc=old-domain,dc=Com cn: ServiceAccount@old-domain.com sn: ServiceAccount@old-domain.com objectClass: person userPassword: {hidden}
When I use the full DN as an argument of the -D option of ldapsearch it works.
I have this in slapd.conf: authz-regexp uid=([^,]*).*,cn=auth cn=$1,dc=old-domain,dc=Com
When I run: slapauth ServiceAccount@old-domain.com I see: ID: ServiceAccount@old-domain.com check succeeded authcID: <cn=ServiceAccount@old-domain.com,dc=old-domain,dc=com> So it looks like it can translate.
But when I try to use: ldapsearch -x -DServiceAccount@old-domain.com ... I get: ldap_bind: Invalid DN syntax (34) additional info: invalid DN
I have a system that sends the "service account" for user searches in this format. I.E. not a DN. I can't change the client.
Does anyone have any ideas why SLAPD does not translate? Or do I need to turn on a "allow non-DNs" switch? Or is it actually the ldapsearch command that is complaining. If the latter, is there a way to test?
Gary
--On Thursday, January 14, 2021 10:27 PM +0000 gary.algier@mavenir.com wrote:
I have this in slapd.conf: authz-regexp uid=([^,]*).*,cn=auth cn=$1,dc=old-domain,dc=Com
When I run: slapauth ServiceAccount@old-domain.com
Does anyone have any ideas why SLAPD does not translate? Or do I need to turn on a "allow non-DNs" switch? Or is it actually the ldapsearch command that is complaining. If the latter, is there a way to test?
From the man page:
authz-regexp <match> <replace> Used by the authentication framework to convert simple user names, such as provided by SASL subsystem, or extracted from certificates in case of cert-based SASL EXTERNAL, or provided within the RFC 4370 "proxied authorization" control, to an LDAP DN used for authorization purposes.
It does not appear to me that you are using a SASL mechanism or the proxied authorization control, but a direct simple bind. Thus the authz-regexp will not fire. Additionally, your users is clearly not binding as "...,cn=auth" so it would never match the authz-regexp you've defined.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
I am not using SASL because the client software does not. It uses simple authentication yet it logs into AD using a non-DN user.
I tested with a translation from the user@domain format and that did not get past slapauth. But I then saw something about these being handled like uid=...,cn=auth. When I changed to that as the regex, it worked on slapauth, but not slapd.
Is there any way to get OpenLDAP to accept a non-DN name with simple auth? It seems to be rejecting the user before any sort of translation.
I also tried "authid-rewriteContext binddn" and "authid-rewriterule" hoping it was early enough in the process.
I can use simple auth with user@domain when authenticating to AD. I can use simple auth with user@domain when authenticating to 389 Directory Server. But I can't use either of those because I need to proxy to AD while translating from the old domain name to the new domain name. 389 DS does not do proxies.
Is there a way to have slapd accept simple authentication but use SASL under the hood to get translations to work?
Gary
--On Thursday, January 14, 2021 11:22 PM +0000 gary.algier@mavenir.com wrote:
I can use simple auth with user@domain when authenticating to AD. I can use simple auth with user@domain when authenticating to 389 Directory Server.
AD is not LDAP, so it lets you do things the LDAP protocol doesn't. 389DS likely has custom code to allow it to behave similar to AD in this instance. You could see about writing a custom overlay that intercepts the bind request and does what you like.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On Thu, Jan 14, 2021 at 10:27:35PM -0000, gary.algier@mavenir.com wrote:
Hello,
I need to bind sometimes with a username that is not in DN format. I have tried to use authz-regexp to translate it but I am not successful.
OpenLDAP will try and normalise the incoming DN and an email-like string is never a valid dn, so there's no way around that.
How limited are your clients? Can they accept a DN to use? Each user in AD still has a relevant entry, so you can use their DN if you can find it.
Regards,
openldap-technical@openldap.org
-
gary.algier＠mavenir.com -
Ondřej Kuzník -
Quanah Gibson-Mount