Hi,
As we store a lot of information in our LDAP server, we are looking to simplify and optimize our LDAP strucutre.
Actually we have plenty OUs (like people and vpn shown hereunder) and lot of fields are duplicate (same fields with same content in different OUs). As this is not optimum and makes us push any change for a user into all concerned OUs, we woul like to use aliasing to avoid duplicating entries:
This is an example of what a user would look like: dn: uid=1,ou=people,dc=red,dc=com objectClass: organizationalPerson objectClass: person objectClass: top objectClass: extensibleObject cn: Frank sn: Moses givenName: Frank Moses mail: frank.moses@red.com userPassword: {SSHA}XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX uid: 1
This is an example of what is to be found in the vpn account of the same user (we have home made schemas, so there are some special attributes): dn: uid=1,ou=vpn,dc=red,dc=com objectClass: top objectClass: openvpn objectClass: extensibleObject uid: 1 cn: Frank sn: Moses userUid: 1 vpnEnabled: TRUE mail: frank.moses@red.com userPassword: {SSHA}XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
As you can see fields cn, sn, mail are the same in both... We would like to change this to make our LDAP more dynamic. Therefore, we changed the vpn account to: dn: uid=1,ou=vpn,dc=red,dc=com objectClass: top objectClass: openvpn objectClass: extensibleObject objectClass: alias uid: 1 aliasedObjectName: uid=1,ou=people,dc=red,dc=com userUid: 1 vpnEnabled: TRUE
But when requesting the server with ldapsearch it seems not to work, or maybe we just are missing someting...! For example when requesting the cn of the vpn user we would like to have the cn field in the "uid=1,ou=people,dc=red,dc=com" account.
Our search: ldapsearch -W -D "cn=admin,dc=red,dc=com" -x -b 'uid=1,ou=vpn,dc=red,dc=com' cn
Gives: # extended LDIF # # LDAPv3 # base <uid=1,ou=vpn,dc=red,dc=com> with scope subtree # filter: (objectclass=*) # requesting: cn #
# 1, vpn, red.com dn: uid=1,ou=vpn,dc=red,dc=com
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
But no "cn" value returned... What are we doing wrong ?
Thank you, Best regards, ZP
Poul Etto wrote:
As we store a lot of information in our LDAP server, we are looking to simplify and optimize our LDAP strucutre.
Actually we have plenty OUs (like people and vpn shown hereunder) and lot of fields are duplicate (same fields with same content in different OUs). As this is not optimum and makes us push any change for a user into all concerned OUs, we woul like to use aliasing to avoid duplicating entries:
There are entry aliases which are somewhat problematic though.
But why do you have such tree structure?
BTW: Using 'extensibleObject' disables schema checking. This is bad practice.
Ciao, Michael.
Hi,
Thank you for answers...
Michael: We didn't know about it... We need such a structure as each of our employees has an account but does not always have access to all our services (and there really are many), so we prefered spliting everything in different OUs.
Quanah: To be honest, we have no LDAP expert in our technical team, so if you have some time to explain how to set it up in a good way, we would be very glad.
Thank you, Best regards, ZP
2015-04-09 21:20 GMT+04:00 Michael Ströder michael@stroeder.com:
Poul Etto wrote:
As we store a lot of information in our LDAP server, we are looking to simplify and optimize our LDAP strucutre.
Actually we have plenty OUs (like people and vpn shown hereunder) and lot of fields are duplicate (same fields with same content in different OUs). As this is not optimum and makes us push any change for a user into all concerned OUs, we woul like to use aliasing to avoid duplicating entries:
There are entry aliases which are somewhat problematic though.
But why do you have such tree structure?
BTW: Using 'extensibleObject' disables schema checking. This is bad practice.
Ciao, Michael.
--On Friday, April 10, 2015 5:02 PM +0400 Poul Etto zepouletto@gmail.com wrote:
Hi,
Thank you for answers...
Michael: We didn't know about it... We need such a structure as each of our employees has an account but does not always have access to all our services (and there really are many), so we prefered spliting everything in different OUs.
That's very poor design.
Quanah: To be honest, we have no LDAP expert in our technical team, so if you have some time to explain how to set it up in a good way, we would be very glad.
The most trivial way to do it is to create a AUX objectClass that has an attribute that tracks which services an employee has access to, and then simply configuring things to use that attribute when allowing access to a system.
olcAttributeTypes: ( companyOID NAME ( 'myCompanyServices' ) DESC 'services an employee has access to' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseIgnoreMatch)
olcObjectClasses: ( myCustomObject NAME 'myCustomObject' DESC 'Custom object for my company' SUP top AUXILIARY MAY ( myCompanyServices $ ) )
Then add that AUX OC onto any account.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Poul Etto wrote:
Thank you for answers...
Michael: We didn't know about it... We need such a structure as each of our employees has an account but does not always have access to all our services (and there really are many), so we prefered spliting everything in different OUs.
You should use group entries for authorization. I'm also using slapo-memberof which automatically adds back link attribute 'memberOf' to group member entries. This gives you best flexibility with most LDAP enabled applications.
Ciao, Michael.
--On Friday, April 10, 2015 11:47 PM +0200 Michael Ströder michael@stroeder.com wrote:
Poul Etto wrote:
Thank you for answers...
Michael: We didn't know about it... We need such a structure as each of our employees has an account but does not always have access to all our services (and there really are many), so we prefered spliting everything in different OUs.
You should use group entries for authorization. I'm also using slapo-memberof which automatically adds back link attribute 'memberOf' to group member entries. This gives you best flexibility with most LDAP enabled applications.
Or you can use slapo-dyngroup with the method I laid out, much more effective IMHO.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Michael Strödermichael@stroeder.com schrieb am 10.04.2015 um 22:47 in
Nachricht 552836EC.3020402@stroeder.com:
Poul Etto wrote:
Thank you for answers...
Michael: We didn't know about it... We need such a structure as each of
our
employees has an account but does not always have access to all our services (and there really are many), so we prefered spliting everything
in
different OUs.
You should use group entries for authorization. I'm also using slapo-memberof which automatically adds back link attribute 'memberOf' to group member entries. This gives you best flexibility with most LDAP enabled applications.
So if you use that approach, can you enable specific groups for saslauthd per application (configuration file)? That sounds interesting, but I don't know how to do it.
Regards, Ulrich
Ulrich Windl wrote:
Michael Strödermichael@stroeder.com schrieb am 10.04.2015 um 22:47 in
Nachricht 552836EC.3020402@stroeder.com:
Poul Etto wrote:
Thank you for answers...
Michael: We didn't know about it... We need such a structure as each of
our
employees has an account but does not always have access to all our services (and there really are many), so we prefered spliting everything
in
different OUs.
You should use group entries for authorization. I'm also using slapo-memberof which automatically adds back link attribute 'memberOf' to group member entries. This gives you best flexibility with most LDAP enabled applications.
So if you use that approach, can you enable specific groups for saslauthd per application (configuration file)? That sounds interesting, but I don't know how to do it.
I don't understand your question. What does "enable [..] for saslauthd" means for you?
Ciao, Michael.
Michael Strödermichael@stroeder.com schrieb am 13.04.2015 um 22:27 in
Nachricht 552C2695.7060703@stroeder.com:
Ulrich Windl wrote:
Michael Strödermichael@stroeder.com schrieb am 10.04.2015 um 22:47 in
Nachricht 552836EC.3020402@stroeder.com:
Poul Etto wrote:
Thank you for answers...
Michael: We didn't know about it... We need such a structure as each of
our
employees has an account but does not always have access to all our services (and there really are many), so we prefered spliting everything
in
different OUs.
You should use group entries for authorization. I'm also using slapo-memberof which automatically adds back link attribute 'memberOf' to group member entries. This gives you best flexibility with most LDAP enabled applications.
So if you use that approach, can you enable specific groups for saslauthd
per
application (configuration file)? That sounds interesting, but I don't know
how
to do it.
I don't understand your question. What does "enable [..] for saslauthd" means for you?
Hi!
I mean: You create a file like /etc/sasl2/smtpd.conf that contains: # cat smtpd.conf pwcheck_method: saslauthd mech_list: plain login -- If saslauthd is configured to use PAM (-a pam), all users that the PAM module finds are valid users for smptd. My question was whether (and how) one can restrict the possible users from the saslauthd configuration file (like smtpd.conf).
Clear now?
Regards, Ulrich
Ulrich Windl wrote:
I mean: You create a file like /etc/sasl2/smtpd.conf that contains: # cat smtpd.conf pwcheck_method: saslauthd mech_list: plain login -- If saslauthd is configured to use PAM (-a pam), all users that the PAM module finds are valid users for smptd. My question was whether (and how) one can restrict the possible users from the saslauthd configuration file (like smtpd.conf).
Hmm, if you don't want all your PAM system users to be valid e-mail users then simply don't use PAM. Sometimes one should rethink the software stack if requirements get more clear. smtpd sounds like postfix which has very flexible LDAP support.
Depending on the PAM/NSS system you're using there could be group authz mechs there too. But you did not provide enough information to really think about this. Personally I prefer to directly use the LDAP features of the software used.
Ciao, Michael.
Michael Strödermichael@stroeder.com schrieb am 14.04.2015 um 09:42 in
Nachricht 552CC4FF.4060600@stroeder.com:
Ulrich Windl wrote:
I mean: You create a file like /etc/sasl2/smtpd.conf that contains: # cat smtpd.conf pwcheck_method: saslauthd mech_list: plain login -- If saslauthd is configured to use PAM (-a pam), all users that the PAM
module
finds are valid users for smptd. My question was whether (and how) one can restrict the possible users from the saslauthd configuration file (like smtpd.conf).
Hmm, if you don't want all your PAM system users to be valid e-mail users then simply don't use PAM. Sometimes one should rethink the software stack if requirements get more clear. smtpd sounds like postfix which has very flexible LDAP support.
Depending on the PAM/NSS system you're using there could be group authz mechs there too. But you did not provide enough information to really think about
this. Personally I prefer to directly use the LDAP features of the software
used.
Hi!
The advantage of the PAM configuration seems to be that you only have to describe your LDAP structure once, and not for every application. I thought there might by a method to restict the accepted users from the sasl configuration file, but it seems there is none.
Thanks!
Ulrich
Ulrich Windl wrote:
Michael Strödermichael@stroeder.com wrote:
Hmm, if you don't want all your PAM system users to be valid e-mail users then simply don't use PAM. Sometimes one should rethink the software stack if requirements get more clear. smtpd sounds like postfix which has very flexible LDAP support.
Depending on the PAM/NSS system you're using there could be group authz mechs there too. But you did not provide enough information to really think about this. Personally I prefer to directly use the LDAP features of the software used.
The advantage of the PAM configuration seems to be that you only have to describe your LDAP structure once, and not for every application.
But if requirements (e.g. set of user accounts) differ you have to define different LDAP client or other configuration anyway. There is no issue if they are the same.
I thought there might by a method to restict the accepted users from the sasl configuration file, but it seems there is none.
Which would somewhat contradict your wish to use the very same configuration anyway.
Ciao, Michael.
Hi,
Thank you for all the information, even if it is going a bit far from the initial question... To clarify the problem, I will try to show what we are doing, you will find here attached an image file that goes with following explanation:
There are "u" user accounts on the ldap server We have a number of "s" services that use LDAP to manage user account. Each service has particular attributes Each service must be able to access only it's information Basic services use only the information contained in the standard LDAP useraccount Advanced services have dedicated OUs with special attributes
It is important that each service can accees in RO (no modification) to only it's information. That's why we made our LDAP as it is in the attached picture.
To simplify usage of services for each user, we decided to duplicate the "password" field between the different OUs, that's why I came here to ask about aliases.
If ever you are sure that there is a cleaner way to do the things (that isn't too heavy to setup), we will be glad to have more technical and logical explanations.
Best regards, ZP
2015-04-14 14:20 GMT+04:00 Michael Ströder michael@stroeder.com:
Ulrich Windl wrote:
Michael Strödermichael@stroeder.com wrote:
Hmm, if you don't want all your PAM system users to be valid e-mail users then simply don't use PAM. Sometimes one should rethink the software stack if requirements get more clear. smtpd sounds like postfix which has very flexible LDAP support.
Depending on the PAM/NSS system you're using there could be group authz mechs there too. But you did not provide enough information to really think about this. Personally I prefer to directly use the LDAP features of the software used.
The advantage of the PAM configuration seems to be that you only have to describe your LDAP structure once, and not for every application.
But if requirements (e.g. set of user accounts) differ you have to define different LDAP client or other configuration anyway. There is no issue if they are the same.
I thought there might by a method to restict the accepted users from the
sasl configuration file, but it seems there is none.
Which would somewhat contradict your wish to use the very same configuration anyway.
Ciao, Michael.
Poul Etto wrote:
Thank you for all the information, even if it is going a bit far from the initial question... To clarify the problem, I will try to show what we are doing, you will find here attached an image file that goes with following explanation:
There are "u" user accounts on the ldap server We have a number of "s" services that use LDAP to manage user account. Each service has particular attributes Each service must be able to access only it's information Basic services use only the information contained in the standard LDAP useraccount Advanced services have dedicated OUs with special attributes
It is important that each service can accees in RO (no modification) to only it's information. That's why we made our LDAP as it is in the attached picture.
To simplify usage of services for each user, we decided to duplicate the "password" field between the different OUs, that's why I came here to ask about aliases.
If ever you are sure that there is a cleaner way to do the things (that isn't too heavy to setup), we will be glad to have more technical and logical explanations.
Can all be done with appropriate ACLs without aliases. Make sure your services authenticate when binding to slapd.
But I can't tell whether it "isn't too heavy" for you. Of course you would have to dive into the ACLs docs.
Ciao, Michael.
Hi,
Thank you for your replies !
@ Quanah: What I understand of their system is that they built their own SCHEMAs... And thay put all information (attributes) in one single OU Is that it ?
@ Michael: Yes, we allready use ACLs (a lot) there is one for each service as each service needs to authenticate before accessing any information and so it is able to read only in "its" OU.
So, you both advice us to use one OU in which we put all attributes and then apply policies with ACLs ?
In our case it would mean that: -The OU people (where basic user informations are stored) would then contain approx 20 attributes. -There would an ACL per service/fields on that OU.
Is that it ?
Thank you, ZP
2015-04-15 1:57 GMT+04:00 Michael Ströder michael@stroeder.com:
Poul Etto wrote:
Thank you for all the information, even if it is going a bit far from the initial question... To clarify the problem, I will try to show what we are doing, you will find here attached an image file that goes with following explanation:
There are "u" user accounts on the ldap server We have a number of "s" services that use LDAP to manage user account. Each service has particular attributes Each service must be able to access only it's information Basic services use only the information contained in the standard LDAP useraccount Advanced services have dedicated OUs with special attributes
It is important that each service can accees in RO (no modification) to only it's information. That's why we made our LDAP as it is in the attached picture.
To simplify usage of services for each user, we decided to duplicate the "password" field between the different OUs, that's why I came here to ask about aliases.
If ever you are sure that there is a cleaner way to do the things (that isn't too heavy to setup), we will be glad to have more technical and logical explanations.
Can all be done with appropriate ACLs without aliases. Make sure your services authenticate when binding to slapd.
But I can't tell whether it "isn't too heavy" for you. Of course you would have to dive into the ACLs docs.
Ciao, Michael.
--On Wednesday, April 15, 2015 7:14 PM +0400 Poul Etto zepouletto@gmail.com wrote:
Hi,
Thank you for your replies !
@ Quanah: What I understand of their system is that they built their own SCHEMAs... And thay put all information (attributes) in one single OU Is that it ?
They extended existing schema, which is part of the whole idea with ldap and schema. And yes, then the data is in a single OU.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Thursday, April 09, 2015 6:49 PM +0400 Poul Etto zepouletto@gmail.com wrote:
This is an example of what is to be found in the vpn account of the same user (we have home made schemas, so there are some special attributes):
This doesn't answer your question, but:
Why didn't you just make your VPN schema extend organizationalPerson and add your attributes there? That's generally the proper way to do things.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Michael Ströder -
Poul Etto -
Quanah Gibson-Mount -
Ulrich Windl