6:49 a.m.
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(a)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(a)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
10:20 a.m.
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.
5:02 a.m.
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(a)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.
12:10 p.m.
--On Friday, April 10, 2015 5:02 PM +0400 Poul Etto <zepouletto(a)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
1:47 p.m.
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.
2:18 p.m.
--On Friday, April 10, 2015 11:47 PM +0200 Michael Ströder
<michael(a)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
11:37 p.m.
New subject: Antw: Re: Help: LDAP using alias to reference value of another attribute
>> Michael Ströder<michael(a)stroeder.com> schrieb am
10.04.2015 um 22:47 in
Nachricht <552836EC.3020402(a)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
1:27 p.m.
New subject: Antw: Re: Help: LDAP using alias to reference value of another attribute
Ulrich Windl wrote:
>>> Michael Ströder<michael(a)stroeder.com> schrieb am
10.04.2015 um 22:47 in
Nachricht <552836EC.3020402(a)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.
11:15 p.m.
New subject: Antw: Re: Help: LDAP using alias to reference value of another attribute
>> Michael Ströder<michael(a)stroeder.com> schrieb am
13.04.2015 um 22:27 in
Nachricht <552C2695.7060703(a)stroeder.com>:
Ulrich Windl wrote:
>>>> Michael Ströder<michael(a)stroeder.com> schrieb am 10.04.2015 um
22:47 in
> Nachricht <552836EC.3020402(a)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
12:42 a.m.
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.
1:59 a.m.
New subject: Antw: Re: Help: LDAP using alias to reference value of another attribute
>> Michael Ströder<michael(a)stroeder.com> schrieb am
14.04.2015 um 09:42 in
Nachricht <552CC4FF.4060600(a)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
3:20 a.m.
Ulrich Windl wrote:
Michael Ströder<michael(a)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.
5:52 a.m.
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(a)stroeder.com>:
Ulrich Windl wrote:
> Michael Ströder<michael(a)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.
2:57 p.m.
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.
7:14 a.m.
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(a)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.
1:47 p.m.
--On Wednesday, April 15, 2015 7:14 PM +0400 Poul Etto
<zepouletto(a)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
10:22 a.m.
--On Thursday, April 09, 2015 6:49 PM +0400 Poul Etto
<zepouletto(a)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
3148
days inactive
3156
days old
openldap-technical@openldap.org
16 comments
4 participants
participants (4)
-
Michael Ströder -
Poul Etto -
Quanah Gibson-Mount -
Ulrich Windl