LDAP

NURDspace Project
Participants	Fwd
Skills
Status
Niche
Purpose
Tool
Location
Cost
Tool category

{{{Name}}}Property "Tool Name" (as page type) with input value "{{{Name}}}" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process. Property "Tool Image" (as page type) with input value "File:{{{Picture}}}" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process. {{{Picture}}} {{#if:{{{Tool}}} | [[Tool Owner::{{{ProjectParticipants}}} | }} {{#if:{{{Tool}}} | [[Tool Cost::{{{Cost}}} | }}

For use with Spacenet we've installed OpenLDAP on NURDServer. On the new NURDServices we're going serious with LDAP.

Connected machines

• Sinterklaas
• Vjdeb
• PrinterPC
• NURDServices
• Proxmox1 (for fixing homedir ownership, only users in group "admins" can actually log in)
• Tankstation

Status

FusionDirectory is running on NURDServices.

It can be accessed on https://ldap.nurdspace.nl.

On Sinterklaas, Vjdeb and the PrinterPC it's working for the local users that existed:

• Homedirs moved to NFS mount from Proxmox1
• Local homedirs and users deleted (except user 'printer' on PrinterPC)
• /home/ is mounted over NFS on boot
• LDAP users can log in and see their homedirs as if nothing has changed
• Users in the LDAP 'sudo' group can sudo on connected workstations.
• Homedir is created on NFS-export when adding a user to LDAP (like this)
• Port 636 (ldaps) is forwarded to NURDServices for future use by the Wiki

Setting up other workstations in this way

To get this to work you need to:

• create all local users in LDAP (if they don't exist already)
• delete local users (optional)
• move homedirs to nurdservices (fix ownership because LDAP-users have a different UID)
• delete local homedirs
• mount /home from proxmox1:/mnt/md0/homedirs over nfs (put it in /etc/fstab)
• install libnss-ldapd and libpam-ldap (URI ldaps://ldap.nurdspace.nl/)
• put https://www.sslcertificaten.nl/files/PositiveSSLCA2.crt in /etc/ssl/certs/ with permissions 644
• in nslcd.conf set the following:

uri ldaps://ldap.nurdspace.nl/
base dc=nurdspace,dc=lan
binddn cn=read-user,ou=systems,dc=nurdspace,dc=lan
bindpw (obtain from other machine)
ssl on
tls_reqcert demand
tls_cacertfile /etc/ssl/certs/PositiveSSLCA2.crt

• restart nslcd
• this information should also be used for pam_ldap.conf
• sudo might not work until you type 'id' which is kind of a mystery

Also useful: http://www.debian-administration.org/article/OpenLDAP_installation_on_Debian#NSS_configuration

In certain cases sudo can break. This can be fixed with a patch while it's not fixed properly.

To do

• Read http://www.openldap.org/doc/admin24/slapdconf2.html
• FTPd nevermind
• Samba nevermind
• Cert installed for ldap.nurdspace.nl. Allow access only over TLS as soon as this works (ldapsearch -v -H ldaps://ldap.nurdspace.nl/ -D uid=fwd,ou=people,dc=nurdspace,dc=lan -W -b dc=nurdspace,dc=lan)
• Fix "nurdservices slapd[32524]: <= bdb_equality_candidates: (uid) not indexed" errors in /var/log/syslog
• Connect machines to LDAP over ldaps instead of ldap.
• Disable non-SSL ldap
• Migrate all local users on Infra machines to LDAP
• Migrate all homedirs to Proxmox1
• Maintain sudo'ers only through the LDAP and disable local root accounts (backdoor in case of emergency?)
• Disable all relevant services on Nurdserver v1
• Upgrade FusionDirectory from 1.0.4 to 1.0.5
• Add all relevant fields of Wiki users to LDAP profiles (this will require Schema extending the schema) we shouldn't want this
• Exclude weak ciphers from olcTLSCipherSuite in cn=config
• Setting "change password on first login" in FusionDirectory doesn't get enforced through PAM
• Create group 'wikiusers' in LDAP
• Add already existing LDAP users to 'wikiusers' group
• Set up VM to test the intended set-up (done on 192.168.1.223) -> Wiki_test_VM
• Merge all unwanted users to use 'history' (running into a bug with some users)
• Inform wiki users that will be renamed
• Migrate/merge wiki users to LDAP
• Create necessary wiki groups (bureaucrats, admins, other?)
• Use LDAP as userdb back-end for wiki (like so)
• Maintain Members page from LDAP (Like so, but this only displays 1 entry. Could be fixed like so.)