On Fri, Aug 09, 2013 at 05:53:57PM +0300, Zeus Panchenko wrote:
To: Andrew Findlay andrew.findlay@skills-1st.co.uk
Please keep replies on the list so that they become searchable and everyone can benefit.
here is the diagram depicting what I am thinking about while talking :)
https://www.dropbox.com/s/212kdpbiug9obkc/org-ldap-diagram-plane.png
I dedicate these DN-s for services, so each such DN *can and supposed to* use any (in theory) uid in the entry, the user can ask for
Do you reall want every user account on every service to have a different username? (i.e. the user cannot request to be known as 'fred' on both the SMTP service and the IMAP service?
in particular, I do not see another way to authenticate users of different domains(for email)/realms(for xmpp) against the same LDAP DB
That depends on how you provide the services. If the network address of the services used by domain-A users is different from that used by domain-B users then the server processes will know which domain they are serving. If the same network address is used to serve all domains then you do indeed require the uids to be unique across domains (but you probably do want to let fred@x.y.com use that ID for all services).
It may be enough for you to simply prevent the non-uniqueness. You can do that using the 'unique' overlay:
mmm ... will not it prevent non-uniqueness only for parent DN-s? while what I'm trying to ask (I'm sorry for muddled up explanation what I mean) about is - uniqueness for the uid *in* the entry ... so, the uniqueness of the attribute `uid' among all DN-s containing authorizedService=target-service
You could do that if you are prepared to have one config line for each service. Something like:
overlay unique unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SMTP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=IMAP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=POP3) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=XMPP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SSH)
Andrew
Andrew Findlay andrew.findlay@skills-1st.co.uk wrote:
Do you reall want every user account on every service to have a different username?
to be honest, I do not want, but in practice when I need to land some mail domain with whole it's users at my MTA, I need to decide what to do with widely used mailboxes like admin, info, abuse etc
(i.e. the user cannot request to be known as 'fred' on both the SMTP service and the IMAP service?
technically I do can provide that but it is head ache of course and what I meant is difference in more "other" protocols like smtp/pop3/imap4 - xmpp - rdp - ftp - ssh - whatever else
are serving. If the same network address is used to serve all domains then you do indeed require the uids to be unique across domains (but you probably do want to let fred@x.y.com use that ID for all services).
yes, I do
mmm ... will not it prevent non-uniqueness only for parent DN-s? while what I'm trying to ask (I'm sorry for muddled up explanation what I mean) about is - uniqueness for the uid *in* the entry ... so, the uniqueness of the attribute `uid' among all DN-s containing authorizedService=target-service
You could do that if you are prepared to have one config line for each service. Something like:
overlay unique unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SMTP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=IMAP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=POP3) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=XMPP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SSH)
wow, great! since the number of the services I provide is limited, it is not the problem to set all of them in slapd.conf
thank you much!
and finally, is it OK (strategically) that object person becomes the branch rather than leaf in such configuration?
Andrew Findlay andrew.findlay@skills-1st.co.uk wrote:
mmm ... will not it prevent non-uniqueness only for parent DN-s? while what I'm trying to ask (I'm sorry for muddled up explanation what I mean) about is - uniqueness for the uid *in* the entry ... so, the uniqueness of the attribute `uid' among all DN-s containing authorizedService=target-service
You could do that if you are prepared to have one config line for each service. Something like:
overlay unique unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SMTP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=IMAP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=POP3) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=XMPP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SSH)
this prevents each uid=X,ou=People,dc=org from having more than one authorizedService=Y offspring ... while the original idea is to let user A to have for the service B, several uid-s but to prevent other users to have the same uids for the corresponding service ...
what I mean are multiple attributes uid/userpassword "inside" the offspring not in the `dn' of the offspring:
dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: john uid: john1 uid: johnN userPassword: qwerty userPassword: qwerty1 userPassword: qwertyN cn: john.doe@xmpp.org sn: xmpp.org description: John Doe XMPP account at xmpp.org uidNumber: 12345 gidNumber: 23456 homeDirectory: /nonexistent loginShell: /sbin/nologin objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: authorizedServiceObject
and in this case we need to prevent some other user from having offspring with the same uid ... to prevent for user uid=johandoe,ou=People,dc=org offspring:
dn: authorizedService=xmpp.org,uid=johandoe,ou=People,dc=org authorizedService: xmpp.org uid: johan uid: johan1 userPassword: qwerty userPassword: qwerty1 cn: johan.doe@xmpp.org sn: xmpp.org description: Johan Doe XMPP account at xmpp.org uidNumber: 12345 gidNumber: 23456 homeDirectory: /nonexistent loginShell: /sbin/nologin objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: authorizedServiceObject
possibility to add another `uid: johnN' which is already used by dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org
so, what could be the solution, please?
On Fri, Sep 27, 2013 at 01:23:54AM -2100, Zeus Panchenko wrote:
overlay unique unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SMTP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=IMAP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=POP3) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=XMPP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SSH)
this prevents each uid=X,ou=People,dc=org from having more than one authorizedService=Y offspring ... while the original idea is to let user A to have for the service B, several uid-s but to prevent other users to have the same uids for the corresponding service ...
what I mean are multiple attributes uid/userpassword "inside" the offspring not in the `dn' of the offspring:
That can be done - it is just a matter of choosing a naming structure that allows it.
dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: john uid: john1 uid: johnN userPassword: qwerty userPassword: qwerty1 userPassword: qwertyN cn: john.doe@xmpp.org sn: xmpp.org description: John Doe XMPP account at xmpp.org uidNumber: 12345 gidNumber: 23456 homeDirectory: /nonexistent loginShell: /sbin/nologin objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: authorizedServiceObject
That one won't work, as there is no way to link the individual uid and userPassword values. You need one LDAP entry per uid so either add another layer to the tree or use multi-valued RDNs. The tree version would look like this:
dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org ....
dn: uid=john,authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: john userPassword: qwerty ....
dn: uid=john1,authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: john1 userPassword: qwerty1 ....
dn: uid=johnN,authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: johnN userPassword: qwertyN ....
The multi-valued RDNs version like this:
dn: uid=john+authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: john userPassword: qwerty ....
dn: uid=john1+authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: john1 userPassword: qwerty1 ....
dn: uid=johnN+authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: johnN userPassword: qwertyN ....
and in this case we need to prevent some other user from having offspring with the same uid ... to prevent for user uid=johandoe,ou=People,dc=org offspring:
dn: authorizedService=xmpp.org,uid=johandoe,ou=People,dc=org authorizedService: xmpp.org uid: johan uid: johan1 userPassword: qwerty userPassword: qwerty1 cn: johan.doe@xmpp.org sn: xmpp.org description: Johan Doe XMPP account at xmpp.org uidNumber: 12345 gidNumber: 23456 homeDirectory: /nonexistent loginShell: /sbin/nologin objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: authorizedServiceObject
possibility to add another `uid: johnN' which is already used by dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org
That should already be covered by the unique overlay setup.
Incidentally, you seem to be misusung some fields in the person object:
cn: john.doe@xmpp.org sn: xmpp.org
If you really don't want to put the real name there you should choose a different objectclass that does not force you to fill in those attributes.
Andrew
Andrew Findlay andrew.findlay@skills-1st.co.uk wrote:
That can be done - it is just a matter of choosing a naming structure that allows it.
that's simple but was not obvious to me :(
That one won't work, as there is no way to link the individual uid and userPassword values. You need one LDAP entry per uid so either add another layer to the tree
dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org ....
dn: uid=john,authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: john userPassword: qwerty ....
I like it, thanks much
have I create dedicated object like: dn: authorizedService=YYY,uid=AAA,dc=ZZZ
before configuring the service for the user like: dn: uid=XXX,authorizedService=YYY,uid=AAA,dc=ZZZ
or the second one will be enough?
Incidentally, you seem to be misusung some fields in the person object:
cn: john.doe@xmpp.org sn: xmpp.org
If you really don't want to put the real name there you should choose a different objectclass that does not force you to fill in those attributes.
it is not to say I do not want to put it, but rather I want to have such possibility in case it could be demanded in the future
as for the different classes ... I was trying to find it but faced the problem when the parent record, which contains objectclass: posixAccount objectclass: inetOrgPerson objectclass: organizationalPerson objectclass: person objectclass: inetLocalMailRecipient
was refusing the child creation until the child belongs to that set of classes :(
On Fri, Sep 27, 2013 at 02:25:24PM +0300, Zeus Panchenko wrote:
have I create dedicated object like: dn: authorizedService=YYY,uid=AAA,dc=ZZZ
before configuring the service for the user like: dn: uid=XXX,authorizedService=YYY,uid=AAA,dc=ZZZ
or the second one will be enough?
You have to create the branch points before you can add entries under them. That is why I suggested the alternative where both the service name and the uid are part of the RDN: such multi-valued RDNs are unusual, but it might be a convenient structure in this case.
as for the different classes ... I was trying to find it but faced the problem when the parent record, which contains objectclass: posixAccount objectclass: inetOrgPerson objectclass: organizationalPerson objectclass: person objectclass: inetLocalMailRecipient
was refusing the child creation until the child belongs to that set of classes :(
There must have been some other reason for the error. LDAP servers do not normally restrict what type of entry you can create at a given point in the DIT. The ACLs in force might restrict what you can do, but you have control over those.
Andrew
Andrew Findlay wrote:
That should already be covered by the unique overlay setup.
Did not follow this thread closely. But one should be aware of ITS#6825 when planning to use slapo-unique for a more complex setup.
unique_uri filter reaching beyond its intended target http://www.openldap.org/its/index.cgi?findid=6825
Ciao, Michael.
On Fri, Sep 27, 2013 at 10:16:43PM +0200, Michael Ströder wrote:
Did not follow this thread closely. But one should be aware of ITS#6825 when planning to use slapo-unique for a more complex setup.
unique_uri filter reaching beyond its intended target http://www.openldap.org/its/index.cgi?findid=6825
Good point. We started with these ACLs:
overlay unique unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SMTP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=IMAP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=POP3) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=XMPP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SSH)
so that bug will prevent modifications to the authority entries even though adds will be processed OK. I cannot think of an easy workaround in this case :-(
Andrew
openldap-technical@openldap.org
-
Andrew Findlay -
Michael Ströder -
Zeus Panchenko