Well, I have a situation (a particular application, actually), that is so arcane in its configuration that it requires that all of the users for the application be in the same OU. So, the config for the app is something like: CN=%USERNAME%,ou=Users,dc=example,dc=com
So, the application substitutes in the %USERNAME% value with the actual username, and then does a bind with the supplied password. My tree is a little more complicated than that - another dc level or two and several different ou=People places - something like this:
ou=People,dc=engineering,dc=example,dc=com ou=People,dc=administration,dc=example,dc=com ou=People,dc=operations,dc=example,dc=com etc.
with all of the users located under the ou=People branches of the tree. What I'm hoping is that there's some way that I can virtually combine the ou=People locations in my LDAP tree such that, when the application requests cn=Nick,ou=users,dc=example,dc=com, it goes out and searches through either the entire dc=example,dc=com tree or goes through and looks at each of the ou=People locations until it finds it and transparently redirects, allowing this application to function correctly in its stupid configuration, but without me having to create a bunch of aliases in a single location in my tree, or, worse, actually reorganize my tree.
I'm thinking there's probably a way to do this with the rewriteRule and some regular expressions, but I can't find quite the combination of rules/expressions to accomplish this. Any ideas? Or am I stuck making aliases?
Thanks, Nick
== This e-mail may contain SEAKR Engineering (SEAKR) Confidential and Proprietary Information. If this message is not intended for you, you are strictly prohibited from using this message, its contents or attachments in any way. If you have received this message in error, please delete the message from your mailbox. This e-mail may contain export-controlled material and should be handled accordingly.
Nick Couchman wrote:
Well, I have a situation (a particular application, actually), that is so arcane in its configuration that it requires that all of the users for the application be in the same OU. So, the config for the app is something like: CN=%USERNAME%,ou=Users,dc=example,dc=com
Sounds like you're trying to integrate a Brocade switch. ;-)
I'm thinking there's probably a way to do this with the rewriteRule and some regular expressions, but I can't find quite the combination of rules/expressions to accomplish this. Any ideas? Or am I stuck making aliases?
Have a closer look at slapo-rwm(5), section REWRITE CONFIGURATION EXAMPLES: http://www.openldap.org/software/man.cgi?query=slapo-rwm
In particular:
# Bind with email instead of full DN: we first need # an ldap map that turns attributes into a DN (the # argument used when invoking the map is appended to # the URI and acts as the filter portion) rwm-rewriteMap ldap attr2dn "ldap://host/dc=my,dc=org?dn?sub"
# Then we need to detect DN made up of a single email, # e.g. `mail=someone@example.com'; note that the rule # in case of match stops rewriting; in case of error, # it is ignored. In case we are mapping virtual # to real naming contexts, we also need to rewrite # regular DNs, because the definition of a bindDN # rewrite context overrides the default definition. rwm-rewriteContext bindDN rwm-rewriteRule "^mail=[^,]+@[^,]+$" "${attr2dn($0)}" ":@I"
Note that if your "application" also uses the DN to determine group membership for authorization you would have to rewrite that too. Gets cumbersome...
For strange network equipment it's sometimes much better to have another protocol frontend using your LDAP server as backend (e.g. RADIUS or TACACS+). For one of my customers using Brocade switches we used the existing TACACS+ server with LDAP backend instead.
Ciao, Michael.
Nick Couchman wrote:
Well, I have a situation (a particular application, actually), that is so arcane in its configuration that it requires that all of the users for the application be in the same OU. So, the config for the app is something like: CN=%USERNAME%,ou=Users,dc=example,dc=com
Sounds like you're trying to integrate a Brocade switch. ;-)
No, if it were a network switch I'd just use RADIUS as you suggested below. It's actually an ERP system that I'll save the name of - and it's built to work more with Active Directory than it is LDAP. I'll also spare this list my feelings on how a certain software mogul likes to butcher standards.
I'm thinking there's probably a way to do this with the rewriteRule and some regular expressions, but I can't find quite the combination of rules/expressions to accomplish this. Any ideas? Or am I stuck making aliases?
Have a closer look at slapo-rwm(5), section REWRITE CONFIGURATION EXAMPLES: http://www.openldap.org/software/man.cgi?query=slapo-rwm
In particular:
# Bind with email instead of full DN: we first need # an ldap map that turns attributes into a DN (the # argument used when invoking the map is appended to # the URI and acts as the filter portion) rwm-rewriteMap ldap attr2dn "ldap://host/dc=my,dc=org?dn?sub" # Then we need to detect DN made up of a single email, # e.g. `mail=someone@example.com'; note that the rule # in case of match stops rewriting; in case of error, # it is ignored. In case we are mapping virtual # to real naming contexts, we also need to rewrite # regular DNs, because the definition of a bindDN # rewrite context overrides the default definition. rwm-rewriteContext bindDN rwm-rewriteRule "^mail=[^,]+@[^,]+$" "${attr2dn($0)}" ":@I"
Note that if your "application" also uses the DN to determine group membership for authorization you would have to rewrite that too. Gets cumbersome...
Okay, I figured it was buried in there somewhere, but my RegEx knowledge is sketchy and I was having trouble deciphering the examples and applying them to these situations. I'll take a closer look at those examples and see if I can work something out. I don't think it does anything with group memberships - just authenticating existing internal user accounts to an external LDAP server.
For strange network equipment it's sometimes much better to have another protocol frontend using your LDAP server as backend (e.g. RADIUS or TACACS+). For one of my customers using Brocade switches we used the existing TACACS+ server with LDAP backend instead.
Ciao, Michael.
Yeah, would that I could just use RADIUS or something like that, but it's a stupid application, at least in terms of external authentication. Thank you very much for taking the time to respond - I appreciate the help!
-Nick
== This e-mail may contain SEAKR Engineering (SEAKR) Confidential and Proprietary Information. If this message is not intended for you, you are strictly prohibited from using this message, its contents or attachments in any way. If you have received this message in error, please delete the message from your mailbox. This e-mail may contain export-controlled material and should be handled accordingly.
----- On Mar 6, 2016, at 12:55 PM, Michael Ströder michael@stroeder.com wrote:
Have a closer look at slapo-rwm(5), section REWRITE CONFIGURATION EXAMPLES: http://www.openldap.org/software/man.cgi?query=slapo-rwm
In particular:
# Bind with email instead of full DN: we first need # an ldap map that turns attributes into a DN (the # argument used when invoking the map is appended to # the URI and acts as the filter portion) rwm-rewriteMap ldap attr2dn "ldap://host/dc=my,dc=org?dn?sub" # Then we need to detect DN made up of a single email, # e.g. `mail=someone@example.com'; note that the rule # in case of match stops rewriting; in case of error, # it is ignored. In case we are mapping virtual # to real naming contexts, we also need to rewrite # regular DNs, because the definition of a bindDN # rewrite context overrides the default definition. rwm-rewriteContext bindDN rwm-rewriteRule "^mail=[^,]+@[^,]+$" "${attr2dn($0)}" ":@I"
Okay, so I'm sure I'm missing something simple, here, but I'm trying out the rewrite using the above examples pretty copied as-is to see if I can just get a bind DN of mail= to turn into the correct full DN. Here are the relevant portions of my config:
## Meta Database for Fronting Real Directory database meta network-timeout 10 nretries 10 suffix "dc=example,dc=com" uri "ldaps://ldap1.example.com/dc=example,dc=com" "ldaps://ldap2.example.com" "ldaps://ldap3.example.com" overlay rwm rwm-rewriteEngine on rwm-rewriteMap ldap attr2dn "ldaps://ldap1.example.com:3636/dc=example,dc=com?dn?sub" rwm-rewriteContext bindDN rwm-rewriteRule "^mail=[^,]+@[^,]+$" "${attr2dn($0)}" ":@I"
I'm not sure how much the order of stuff matters, here - I'll try out a few variations on that - but the above doesn't yield a good result when I try to connect with: ldapsearch -b dc=example,dc=com -D mail=account.one@example.com -W -x cn=Some\ User
I enter the password for the user associated with the e-mail address account.one@example.com, and just get an Invalid Credentials result. Also, I've tried various debugging levels and am not seeing any debug messages related to the rwm overlay - nothing indicating that it picked up on the mail= bindDN and tried to search/convert that to a "real" DN.
Thanks, Nick
== This e-mail may contain SEAKR Engineering (SEAKR) Confidential and Proprietary Information. If this message is not intended for you, you are strictly prohibited from using this message, its contents or attachments in any way. If you have received this message in error, please delete the message from your mailbox. This e-mail may contain export-controlled material and should be handled accordingly.
----- On Mar 6, 2016, at 2:17 PM, Nick E Couchman nick.couchman@seakr.com wrote:
----- On Mar 6, 2016, at 12:55 PM, Michael Ströder michael@stroeder.com wrote:
Have a closer look at slapo-rwm(5), section REWRITE CONFIGURATION EXAMPLES: http://www.openldap.org/software/man.cgi?query=slapo-rwm
In particular:
# Bind with email instead of full DN: we first need # an ldap map that turns attributes into a DN (the # argument used when invoking the map is appended to # the URI and acts as the filter portion) rwm-rewriteMap ldap attr2dn "ldap://host/dc=my,dc=org?dn?sub" # Then we need to detect DN made up of a single email, # e.g. `mail=someone@example.com'; note that the rule # in case of match stops rewriting; in case of error, # it is ignored. In case we are mapping virtual # to real naming contexts, we also need to rewrite # regular DNs, because the definition of a bindDN # rewrite context overrides the default definition. rwm-rewriteContext bindDN rwm-rewriteRule "^mail=[^,]+@[^,]+$" "${attr2dn($0)}" ":@I"
Okay, so I'm sure I'm missing something simple, here, but I'm trying out the rewrite using the above examples pretty copied as-is to see if I can just get a bind DN of mail= to turn into the correct full DN. Here are the relevant portions of my config:
## Meta Database for Fronting Real Directory database meta network-timeout 10 nretries 10 suffix "dc=example,dc=com" uri "ldaps://ldap1.example.com/dc=example,dc=com" "ldaps://ldap2.example.com" "ldaps://ldap3.example.com" overlay rwm rwm-rewriteEngine on rwm-rewriteMap ldap attr2dn "ldaps://ldap1.example.com:3636/dc=example,dc=com?dn?sub" rwm-rewriteContext bindDN rwm-rewriteRule "^mail=[^,]+@[^,]+$" "${attr2dn($0)}" ":@I"
I'm not sure how much the order of stuff matters, here - I'll try out a few variations on that - but the above doesn't yield a good result when I try to connect with: ldapsearch -b dc=example,dc=com -D mail=account.one@example.com -W -x cn=Some\ User
Answering my own question here - found another post that indicated rwm stuff needed to be before the database declaration. Moved it up and this is working perfectly, and I think will make this silly application's LDAP "implementation" actually work with my directory tree. Thanks very much for the help!
-Nick
== This e-mail may contain SEAKR Engineering (SEAKR) Confidential and Proprietary Information. If this message is not intended for you, you are strictly prohibited from using this message, its contents or attachments in any way. If you have received this message in error, please delete the message from your mailbox. This e-mail may contain export-controlled material and should be handled accordingly.
openldap-technical@openldap.org