LDAP

From NURDspace
Revision as of 23:42, 3 June 2013 by Fwd (talk | contribs) (→‎Wiki)
NURDspace Project
link=File:{{{Name}}}.jpg
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.

Status

Slapd and FusionDirectory are running on NURDServices. FusionDirectory can be accessed on https://ldap.nurdspace.nl.

Connected machines and services

Workstations

The workstations listed above are set up as follows:

  • Homedirs mounted over NFS from Proxmox1 (except user 'printer' on PrinterPC)
  • Users in the LDAP 'sudo' group can sudo.
  • Homedirs are created on the NFS-export when adding a user to LDAP (like this)

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)
  • put https://www.sslcertificaten.nl/files/PositiveSSLCA2.crt in /etc/ssl/certs/ with permissions 644
  • install libnss-ldapd and libpam-ldap (URI ldaps://ldap.nurdspace.nl/)
  • the installation of libnss-ldap and libpam-ldap don't offer all required settings, so fix nslcd.conf and pam_ldap.conf to mention at least 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

Useful reading: http://www.debian-administration.org/article/OpenLDAP_installation_on_Debian

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

Wiki

#LDAP Auth
require_once( "$IP/extensions/LdapAuthentication/LdapAuthentication.php" );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDebug = 9;
$wgDebugLogGroups['ldap'] = '/tmp/debug.log';

$wgLDAPDomainNames = array( 'nurdspace.lan', );
$wgLDAPServerNames = array( 'nurdspace.lan' => 'ldap.nurdspace.nl', );
$wgLDAPUseLocal = false;
$wgLDAPEncryptionType = array( 'nurdspace.lan' => 'ssl', );
$wgLDAPSearchStrings = array( 'nurdspace.lan' => 'uid=USER-NAME,ou=people,dc=nurdspace,dc=lan', );
$wgLDAPLowerCaseUsername = array( 'nurdspace.lan' => true );
$wgLDAPRequiredGroups = array( 'nurdspace.lan' => array( 'cn=wikiusers,ou=groups,dc=nurdspace,dc=lan', ) );
$wgLDAPGroupUseFullDN = array( "nurdspace.lan"=>false );
$wgLDAPGroupObjectclass = array( "nurdspace.lan"=>"posixGroup" );
$wgLDAPGroupAttribute = array( "nurdspace.lan"=>"memberUid" );
$wgLDAPGroupSearchNestedGroups = array( "nurdspace.lan"=>false );
$wgLDAPGroupNameAttribute = array( "nurdspace.lan"=>"cn" );
$wgLDAPBaseDNs = array( "nurdspace.lan"=>"dc=nurdspace,dc=lan" );
$wgLDAPUseLDAPGroups = array( "nurdspace.lan"=>true );
$wgGroupPermissions['wikiusers']['edit'] = true;
$wgGroupPermissions['admins'] = $wgGroupPermissions['sysop'];

# This hook is called by the LdapAuthentication plugin. It is a configuration hook. Here we
# are specifying what attibute we want to use for a username in the wiki.
# Note that this hook is NOT called on a straight bind.
# The hook calls the function defined below.
$wgHooks['SetUsernameAttributeFromLDAP'][] = 'SetUsernameAttribute';

Some settings might not be necessary, such as the wgGroupPermissions and wgHooks. I'll do some experimenting to see if it can be cleaned up.

Limitations

Wifi

The LDAP serves as a userdb for Spacenet, which is connected via FreeRADIUS. For full details see the Spacenet-page.

Future plans

The most important machines and services are now hooked up to the LDAP. However, there's always room for more.

More groups for different purposes

We should create more groups for specific purposes, such as:

  • Workstation users (now only sudo'ers are treated separately)
  • Separate group per workstation? Or some sort of hierarchy of groups, so members need only be in 1 group?
  • Spacenet users (currently all with SMB-entry, which also works but isn't as nice)

(Un)locking the front door

See Spacelock.

Member registration

Currently the users in group "members" are maintained by hand. A little more automation would be appropriate. Hooking it up to actual money transactions might be far-fetched, but maybe something else is possible.

Make use of more of FusionDirectory's features

FusionDirectory has features/plugins for applications, mime-types, workstations, object groups, public key authentication. Maybe some of these could be useful?

Misc

  • Investigate possibility of moving to a different database back-end ([back-sql])
  • Exclude weak ciphers from olcTLSCipherSuite in cn=config
  • Setting "change password on first login" in FusionDirectory doesn't get enforced through PAM
  • Upgrade FusionDirectory from 1.0.5 to 1.0.6
  • Maintain Members page from LDAP (Like so, but this only displays 1 entry. Could be fixed like so.)
  • Check if the passwordmailer on FusionDirectory works
Retrieved from "https://nurdspace.nl/index.php?title=LDAP&oldid=2935"