Hi,
My primary goal with an openldap directory is to store information to manage people authentification and autorisation to resources on my local network. But I also feel this directory to be a cool opportunity to maintain a registry that would include administrative information such as telephone number.
Here is the DIT structure that I plan to deploy to to do that.
If anyone has a comment or advice I would be grateful !
Summary : | ----------------------------- | STAFF=organizationalUnit | ----------------------------- _____| | | | | | | | | -> [ one entry per employee ] | | ------------------------- | John Doe=inetOrgPerson | -> [administrative data such as tel number] ------------------------- | ------------------ | doe=posixAccount | -> [ uid, password on so on ] ------------------
LDIF :
Staff is a branch of people :
# Entry 1: ou=staff,ou=people,dc=example,dc=fr dn: ou=staff,ou=people,dc=example,dc=fr objectclass: organizationalUnit objectclass: top ou: staff
that contains as many inetOrgPerson as I have people in staff (here are recorded administrative data such as telephone number and so on) :
# Entry 12: uid=doe,ou=staff,ou=people,dc=example,dc=fr dn: sn=doe,ou=staff,ou=people,dc=example,dc=fr sn: doe cn: john doe objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson
Each "inetOrgPerson" may also have a "posixAccount" child that record information usable to access resources :
dn: uid=doe,sn=doe,ou=staff,ou=people,dc=example,dc=fr cn: john doe gidnumber: 1800 homedirectory: /home/doe loginshell: /bin/tcsh objectclass: account objectclass: posixAccount objectclass: top objectclass: shadowAccount uid: doe uidnumber: 510 userpassword: {SSHA}***********************
--- Olivier
Hi.
On 08/18/2011 10:46 AM, Olivier wrote:
Hi,
My primary goal with an openldap directory is to store information to manage people authentification and autorisation to resources on my local network. But I also feel this directory to be a cool opportunity to maintain a registry that would include administrative information such as telephone number.
Here is the DIT structure that I plan to deploy to to do that.
If anyone has a comment or advice I would be grateful !
Summary : | ----------------------------- | STAFF=organizationalUnit | ----------------------------- _____| | | | | | | | | -> [ one entry per employee ] | |
| John Doe=inetOrgPerson | -> [administrative data such as tel number]
|
| doe=posixAccount | -> [ uid, password on so on ]
What a reason for split user account data to two objects?
WBR
LDIF :
Staff is a branch of people :
# Entry 1: ou=staff,ou=people,dc=example,dc=fr dn: ou=staff,ou=people,dc=example,dc=fr objectclass: organizationalUnit objectclass: top ou: staff
that contains as many inetOrgPerson as I have people in staff (here are recorded administrative data such as telephone number and so on) :
# Entry 12: uid=doe,ou=staff,ou=people,dc=example,dc=fr dn: sn=doe,ou=staff,ou=people,dc=example,dc=fr sn: doe cn: john doe objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson
Each "inetOrgPerson" may also have a "posixAccount" child that record information usable to access resources :
dn: uid=doe,sn=doe,ou=staff,ou=people,dc=example,dc=fr cn: john doe gidnumber: 1800 homedirectory: /home/doe loginshell: /bin/tcsh objectclass: account objectclass: posixAccount objectclass: top objectclass: shadowAccount uid: doe uidnumber: 510 userpassword: {SSHA}***********************
Olivier
Dmitriy Kirhlarov dimma@higis.ru:
What a reason for split user account data to two objects?
Good question, thanks Dimitry !
Here is the problem I had when I tried to merge all info in the same object :
$ ldapadd -x -D "cn=Manager,dc=example,dc=fr" -w secret -H ldap://ldap-master1example.fr -f person.ldif
adding new entry "uid=olivier,ou=staff,ou=people,dc=example,dc=fr" ldap_add: Object class violation (65) additional info: invalid structural object class chain (inetOrgPerson/account)
$ cat person.ldif
dn: uid=olivier,ou=staff,ou=people,dc=example,dc=fr uid: olivier uidnumber: 1222 sn: olivier cn: Olivier Doe objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectclass: account objectclass: posixAccount objectclass: shadowAccount gidnumber: 18004 homedirectory: /home/olivier loginshell: /bin/tcsh userpassword: {SSHA}ttiFPj/uYlfSACRO2Gr/R0y9nzRHiMBW
If I don't use the "objectclass: account" it works.
But if I do that is that I don't get anymore the attribute "host" that could have been useful to tune accesses to certain equipements.
--- Olivier
Oliver,
Olivier schrieb:
Dmitriy Kirhlarov dimma@higis.ru:
What a reason for split user account data to two objects?
Good question, thanks Dimitry !
Here is the problem I had when I tried to merge all info in the same object :
$ ldapadd -x -D "cn=Manager,dc=example,dc=fr" -w secret -H ldap://ldap-master1example.fr -f person.ldif
adding new entry "uid=olivier,ou=staff,ou=people,dc=example,dc=fr" ldap_add: Object class violation (65) additional info: invalid structural object class chain (inetOrgPerson/account)
acount and inetorgperson are both structural, so you cannot use them in one object. If you need the attribute host in your object and you do not find an appropriate auxiliary object class, then build a schema with your own object class yourself.
Marc
On Thursday, 18 August 2011 11:26:33 Olivier wrote:
Dmitriy Kirhlarov dimma@higis.ru:
What a reason for split user account data to two objects?
Good question, thanks Dimitry !
Here is the problem I had when I tried to merge all info in the same object :
$ ldapadd -x -D "cn=Manager,dc=example,dc=fr" -w secret -H ldap://ldap-master1example.fr -f person.ldif
adding new entry "uid=olivier,ou=staff,ou=people,dc=example,dc=fr" ldap_add: Object class violation (65) additional info: invalid structural object class chain (inetOrgPerson/account)
$ cat person.ldif
dn: uid=olivier,ou=staff,ou=people,dc=example,dc=fr uid: olivier uidnumber: 1222 sn: olivier cn: Olivier Doe objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectclass: account objectclass: posixAccount objectclass: shadowAccount gidnumber: 18004 homedirectory: /home/olivier loginshell: /bin/tcsh userpassword: {SSHA}ttiFPj/uYlfSACRO2Gr/R0y9nzRHiMBW
If I don't use the "objectclass: account" it works.
Use hostObject from ldapns.schema, shipped with pam_ldap.
http://svnweb.mageia.org/packages/cauldron/openldap-extra- schemas/current/SOURCES/ldapns.schema?view=markup
or
http://svnweb.mageia.org/packages/cauldron/openldap-extra- schemas/current/SOURCES/ldapns.ldif?view=markup
Regards, Buchan
openldap-technical@openldap.org
-
Buchan Milne -
Dmitriy Kirhlarov -
Marc Patermann -
Olivier