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