[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: separate login/password for several services?



On Fri, Aug 09, 2013 at 04:17:02PM +0300, Zeus Panchenko wrote:

> the uniqueness while *creating* the dn ... since for dn-s
> 
> dn: authorizedService=target-service,uid=target-user1,ou=People,dc=org
> dn: authorizedService=target-service,uid=target-user2,ou=People,dc=org
> ...
> dn: authorizedService=target-service,uid=target-userN,ou=People,dc=org
> 
> I want to prevent the possibility to create the same uid=john-whatever-format-it-is 

If you always put the uid in the DN using the structure shown above
then it will not be possible to create duplicates. That assumes that
you use the same uid in all the subentries of the main user entry...

> now I do can ldapadd these ldif-s successfully
> ---[ ldif ]------------------------------------------------------------
> dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org
> authorizedService: xmpp.org
> 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
> uid: john
> 
> dn: authorizedService=xmpp.org,uid=jsmith,ou=People,dc=org
> authorizedService: xmpp.org
> cn: john.smith@xmpp.org
> sn: xmpp.org
> description: John Smith XMPP account at xmpp.org
> uidNumber: 12356
> gidNumber: 23456
> homeDirectory: /nonexistent
> loginShell: /sbin/nologin
> objectClass: person
> objectClass: posixAccount
> objectClass: shadowAccount
> objectClass: authorizedServiceObject
> uid: john
> ---[ ldif ]------------------------------------------------------------

Both those entries have one uid in the entry and a different one in
the DN. The one in the DN refers to the parent entry in each case so
it is legal but maybe not what you want.

It may be enough for you to simply prevent the non-uniqueness. You can
do that using the 'unique' overlay:

overlay unique
unique_uri ldap:///ou=People,dc=org?uid?sub

Unfortunately this creates another problem: *every entry* must have a
different uid - probably not what you want...

It would be possible to write an access-control list using sets to
require that the two uids match. This is not quite as simple as there
are various cases to consider. Again it may be too restrictive, as
then every sub-entry would have to have the same uid as the main entry
(though the passwords could still be different).

> > If each 'john' account exists in a distinct identifiable namespace then
> > you could either put the name of the namespace in the account entry or
> > you could use it as part of the LDAP hierachy. The application can
> > then formulate a search that finds the correct entry in one operation.
> 
> I was thinking to use sn: attribute since it is login dedicated dn: and
> it is no need in it

The data you are putting there is clearly *not* a surname. Don't
misuse attributes like this - it will cause trouble later. A more
appropriate attribute might be associatedDomain - you will need to add
the objectclass 'domainRelatedObject' as well.

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     |
-----------------------------------------------------------------------