[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: separate login/password for several services?
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
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------