New LDAP structure for Debian Edu
With the development of the Squeeze based version of Debian Edu, work is done to look at the LDAP directory structure used. Part of the background for this is that the traditional web interface to administrate users and computers in LDAP, LWAT, no longer is working, and an alternative is considered.
The LDAP structure in Debian Edu/Lenny
- dc=skole,dc=skolelinux,dc=no (base for NSS)
- ou=People (posixAccount entries)
- ou=Machines (host entries for samba)
- ou=Group (posixGroup entries)
- ou=Netgroup
- ou=Automount
- ou=Variables
- ou=Attic
- ou=hosts (DNS forward and reverse entres for all hosts)
- cn=dhcp (DHCP server entry with config reference)
- cn=DHCP Config (DHCP configuration and host entries)
- ou=Attic
- ou=Pam (unused)
- ou=Domains (unused)
- ou=People (posixAccount entries)
A computer / IP device have three or four LDAP objects, two under hosts (forward and reverse DNS and one under DHCP Config (MAC -> DNS name mapping). Samba clients have one object under People->Machines as well.
All users have posixAccount, and their user names might be listed in posixGroup and nisNetgroup objects.
Requirements
- Need to work with NSS (libnss-ldapd or sssd).
- Need to work with PowerDNS using LDAP backend.
- Need to work with ISC DHCP using LDAP backend.
Wishes for the new structure
The NSS part of the LDAP tree should be separated into a subtree, to allow LDAP objects to be moved outside this subtree to become invisible in NSS. This is useful when moving users to the attic instead of just removing them to make it easy to restore a disabled/"removed" user when needed. (Why use an attic? Why not use a deleted attribute? - because the default setup for LDAP NSS clients is to look for objectclass=posixaccount without any more filtering, and it is a pain to have to add more filtering to these clients. better to move the object to an unseen part of the LDAP tree [pere 2010-07-09])
- Having only one LDAP objects for each computer to avoid the possibility of having inconsistent setup for computers in LDAP. At the moment there are several, one DHCP object, one forward DNS object, one reverse DNS object and one Samba host object (are there more?).
- Allowing several departments/schools to share the same structure while allowing delegation of privileges to the users/groups/computers in each department.
- Storing LDAP objects for central services separately from the users and groups belonging to schools, to allow access to these to be different from the users and groups.
a subtree for people exported in the format specified by the FEIDE project in Norway. It is a federation specification for cross-site authentication.
- the structure should be as simple as possible, but allow for a more complex / structured setup for schools that want it or for sites administrating several schools using the same LDAP database.
- The most used setup is afaik having one server for one school, independently from other schools in the same municipality. I would like to have an advanced setup, where the DIT is splitted to several subtrees which are on separate servers in different schools belonging to one municpality, holding the master.
Ideas for a new structure
- As LDAP is case insensitive, use only one case for all names (lower case?).
Related LDAP schemas and references
Overview what kind of DIT is used in CipUX http://wiki.cipux.org/documentation/dit
I (jever) found today [2010-07-10] this and this diagram describing something we perhaps want. For those who can read German, there are four articles describing the setup shown in the diagrams. The first can be found here. The others are linked from there so everyone interested can find them.
suggestion / idea
This is not ment as a concrete proposal, but instead as a starting point for the discussion (Petter)
- dc=skole,dc=skolelinux,dc=no
- ou=unixsystem (NSS clients are pointed to this subtree)
- ou=netgroups
- ou=filegroups
- ou=users
- ou=ipdevices (computers, printers, etc)
- ou=school1
- ou=netgroups
- ou=filegroups
- ou=users
- ou=ipdevices
- ou=school2
- ...
- ou=ipnetworks
- ou=services
- ou=kerberos
- ou=dhcp
- ou=dns
- dc=intern (SOA entry)
- dc=_tcp
- dc=_ldap (SRV entry)
- dc=ldap (CNAME)
- dc=_tcp
- dc=intern (SOA entry)
- ou=samba
- sambaDomainName=SKOLELINUX
- cn=smbadmin
- ou=mail
- ou=automount
- ou=templates
- ou=attic
- ou=netgroups
- ou=filegroups
- ou=users
- ou=feide
- ou=unixsystem (NSS clients are pointed to this subtree)
the ipdevices subtrees should include the host specific information used by DNS, DHCP and Samba. The user object should contain information used by Kerberos and the mail system. the services subtree should only have the common setup. the user and ipdevice specific information should be in the unixsystem subtree.
The proposal above expects to use the same service department for ou=school1 and ou=school2. It might be better to use independent services. Perhaps it is possible to use a tree dc=skole1,dc=skolelinux,dc=no in school1 and a tree dc=skole2,dc=skolelinux,dc=no in school2, and unite these trees if a single admin takes care of both systems.
Overview what kind of DIT is used in CipUX http://wiki.cipux.org/documentation/dit
Example Structure with GOsa²
The following structure is what I (andi) had in mind when experimenting with GOsa²:
- dc=skole,dc=skolelinux,dc=no
- ldap-admin
- gosa-admin
- ou=SUDOers
- root
- defaults
- debian-edu (propagate changes in ldap to the system)
- ou=kerberos
- ou=INTERN
- machine principals
- service principals
- ...
- kadmin-service
- kdc-service
- ou=INTERN
- ou=Automount
- ou=auto.master
- ou=auto.skole
- ou=auto.tjener
- ou=Students
- ou=groups
- ou=people
- ou=systems
- ou=Teachers
- ou=groups
- ou=people
- ou=systems
- ou=Machines
- ou=systems
- ou=netdevices
- workstation.intern
- ou=servers
- tjener.intern
- dhcp
- zoneName=intern
- relativeDomainName
- ...
- tjener.intern
- ou=netdevices
- ou=systems
Every school is free to add more departments, for example something like:
- ou=Students
- ou=2010a
- ou=2010b
or
- ou=Machines
- ou=RoomIT01
- ou=systems
- ....
- ou=systems
- ou=RoomIT02
- ou=RoomIT01
In each of these departments ou=groups and ou=people are created when a user and his group are created. If a machine is created, it is placed in the corresponding ou=systems. Another possible structure:
- ou=Building01
- ou=people
- ou=groups
- ou=systems
- ou=Building02
- ....
In GOsa², by choosing a task, for example Users, only the objects of ou=people are displayed for a specific department. If you choose Systems, only the machines in systems are displayed and what might look a bit confusing here is quite nice and flexible.
GOsa² based computer structure
here i paste to differents computers from a GOsa² working environment, the first one is a basic computer with also the dhcp / dns entries, those entries are created when save it clicked on the interface.
dn: cn=compute-node-1-5,ou=workstations,ou=systems,dc=acme,dc=be gotoNtpServer: vador cn: compute-node-1-5 ghSoundAdapter: - gotoLastUser: - gotoLdapServer: 1:vador:ldap://vador.acme.be:389/dc=acme,dc=be FAIdebianMirror: http://vador.acme.be/debian/ gotoXColordepth: 8 gotoXKbLayout: fr gotoXKbVariant: nodeadkeys gotoXMouseport: /dev/input/mice goFonHardware: automatic objectClass: top objectClass: gotoWorkstation objectClass: GOhard objectClass: FAIobject macAddress: 00:1c:c4:97:72:18 gotoXResolution: 1280x1024 ghCpuType: AuthenticAMD / Dual-Core AMD Opteron(tm) Processor 8220 - 2813.052 gotoXKbModel: pc104 ghGfxAdapter: ATI ES1000 515E ghMemSize: 16473316 gotoXMouseType: explorerps/2 ghUsbSupport: true gotoXHsync: 30-95 gotoXDriver: radeon gotoXVsync: 40-100 gotoXMonitor: Smart Cable gotoHardwareChecksum: EzzPkhDW6YB+9spP+ixamA gotoBootKernel: linux-image-2.6-amd64 FAIclass: NOEUD-BASE :squeeze FAIstate: install ipHostNumber: 10.151.53.135 description:: T3B0ZXJvbiBxdWFkcmktcHJvIG7CsDU= gotoMode: locked ghIdeDev: TSSTcorpCDW/DVD TS-L462D ghNetNic: Broadcom NetXtreme II BCM5706 Gigabit Ethernet gotoModules: amd74xx gotoModules: ata_generic gotoModules: aufs gotoModules: auth_rpcgss gotoModules: bnx2 gotoModules: cciss gotoModules: cdrom gotoModules: exportfs gotoModules: fan gotoModules: fscache gotoModules: hid gotoModules: ib_mad gotoModules: ide_cd_mod gotoModules: ide_core gotoModules: ide_generic gotoModules: ide_pci_generic gotoModules: ipmi_msghandler gotoModules: ipmi_si gotoModules: joydev gotoModules: k8temp gotoModules: libata gotoModules: lockd gotoModules: nfs gotoModules: processor gotoModules: psmouse gotoModules: serio_raw gotoModules: shpchp gotoModules: soundcore gotoModules: sunrpc gotoModules: thermal gotoModules: thermal_sys gotoModules: uhci_hcd gotoModules: usbhid dn: cn=compute-node-1-5,cn=dhcp, cn=vador,ou=servers,ou=systems,dc=acme,dc=be dhcpOption: host-name compute-node-1-5 dhcpStatements: fixed-address 10.10.53.135 cn: compute-node-1-5 objectClass: top objectClass: dhcpHost dhcpHWAddress: ethernet 00:1c:c4:97:72:18 dn: relativeDomainName=compute-node-1-5,zoneName=hpslab.acme.be., cn=vador,ou=servers,ou=systems,dc=hpslab,dc=acme,dc=be objectClass: top objectClass: dNSZone dNSClass: IN zoneName: hpslab.acme.be. relativeDomainName: compute-node-1-5 dn: relativeDomainName=compute-node-1-5,relativeDomainName=compute-node-1-5,zoneName=hpslab.acme.be., cn=vador,ou=servers,ou=systems,dc=hpslab,dc=acme,dc=be objectClass: top objectClass: dNSZone dNSClass: IN zoneName: hpslab.acme.be. relativeDomainName: compute-node-1-5 aRecord: 10.10.53.135
The second one is a server
dn: cn=vador,ou=servers,ou=systems,dc=hpslab,dc=acme,dc=be cn: vador macAddress: 00:1b:78:37:38:0e gotoMode: locked gotoSysStatus: new-system ghNetNic: Hewlett-Packard Company HP 110T PCIe Gigabit Server Adapter ghCpuType: GenuineIntel / Intel(R) Xeon(R) CPU 5160 @ 3.00GHz - 2999.963 gotoXKbModel: pc104 ghGfxAdapter: ATI ES1000 515E ghMemSize: 10267704 gotoXMouseType: explorerps/2 ghUsbSupport: true gotoXHsync: 30+50 gotoXDriver: radeon gotoXVsync: 30+90 gotoHardwareChecksum: V4KCoPLkQgGtJ6eYH7FnNA ghIdeDev: HL-DT-ST DVDRAM GSA-T20L dhcpServiceDN: cn=dhcp,cn=vador,ou=servers,ou=systems,dc=hpslab,dc=acme,dc=be description: frontal cluster hpslab FAIstate: install FAIdebianMirror: auto ipHostNumber: 10.10.53.160 gotoBootKernel: default gotoModules: auth_rpcgss gotoModules: crc_t10dif gotoModules: edac_core gotoModules: exportfs gotoModules: i5k_amb gotoModules: ib_mad gotoModules: ide_core gotoModules: ide_gd_mod gotoModules: ipmi_msghandler gotoModules: ipmi_si gotoModules: loop gotoModules: lp gotoModules: reiserfs gotoModules: sd_mod gotoModules: serio_raw gotoModules: sg gotoModules: shpchp gotoModules: sr_mod gotoModules: thermal goTimeSource: 130.58.102.1 FAIrepository: http://vador.acme.be/debian/|debian.acme.be|squeez e|main,contrib,non-free FAIrepository: http://vador.acme.be/debian/|debian.acme.be|lenny| main,contrib,non-free FAIrepository: http://vador.acme.be/debian-security/|debian.acme.be|lenny/updates|main,contrib,non-free objectClass: GOhard objectClass: top objectClass: goServer objectClass: gotoWorkstationTemplate objectClass: FAIobject objectClass: dhcpServer objectClass: FAIrepositoryServer objectClass: goLdapServer objectClass: goNtpServer goLdapBase: ldap://vador.acme.be:389/dc=hpslab,dc=acme,dc=be
It should be possible to make the DNS ldap objects compatible with the powerdns strict LDAP mode by adding the domainrelatedobject object class from the cosine LDAP schema , and the DNS FQDN in its associatedDomain attribute. The object would then look like this:
dn: relativeDomainName=compute-node-1-5,relativeDomainName=compute-node-1-5,zoneName=hpslab.acme.be.,cn=vador,ou=servers,ou=systems,dc=hpslab,dc=acme,dc=be objectClass: top objectClass: dNSZone objectClass: domainrelatedobject dNSClass: IN zoneName: hpslab.acme.be. relativeDomainName: compute-node-1-5 associatedDomain: compute-node-1-5.hpslab.acme.be aRecord: 10.10.53.135