IT-Syndikat/its-network
27
0
Fork 1
Code Issues1 Pull requests Projects Releases Packages Wiki Activity Actions
its-network/docs/space/srv-acraze/ldap.md
Xiretza 4841d40ecd Prettify
2025-03-16 12:52:11 +00:00

8.2 KiB
Raw Permalink Blame History

About

This file contains the documentation of the it-sydikat ldap server at ldap.it-syndikat.org/blacksunempire.srv.it-syndikat.org, residing on acraze

Maintainers

Current Maintainers:

  • tyrolyean: Setup and maintenance.

OS

The servers are running debian stable as operating system and are using openldap from the debian repositories. Core ldap structure was created by dpkg during installation.

LDAP

Nomenclature

LDAP word Meaning in the real world
dn Distinctive Name - The object/user/group/etc's FQDN in the tree
cn Common name - Usually the part of the DN that is last/object identifying
bind dn DN of the account you are trying to bind to. Usually requires a password
dc Domain component
ou Organizational Unit
ldif File defining a change in the ldap tree of some sort
adminDN DN of the ldap tree administrator. NEVER STORE ON ANY SERVICE!

Note on pasted ldif files

If you are building a new ldap server based on the below ldif files, please be aware that default ldap entries change over time as the overall structure evolves and you may have to insert a value into a different dn than in the paste below, or you may have to alter a add operation to be a replace. Openldap may give some seemingly useless error messages if you have never operated one before, but it is very consistent in it's stupidities, you'll get used to it.

Tree structure

The base-dn configured is dc=it-syndikat,dc=org.

  • Admin DN: cn=admin,dc=it-syndikat,dc=org
  • User DN: ou=users,dc=it-syndikat,dc=org
  • Group DN: ou=groups,dc=it-syndikat,dc=org
  • Services DN: ou=services,dc=it-syndikat,dc=org
  • Config: cn=config

groups

Groups are stored in the posixGroup format, which means membership information resides with the group, not the user. This style must be kept due to an ACL, allowing a user to modify non-structural information of a user-entry at will.

Groups ending in -admin grant its members administrative privileges on the corresponding services. There currently is no all users group to prevent people from using it when they actually meant something else0. This may change in the future if the need arises.

User accounts

User accounts are required to fullfill the following objectClasses:

  • top: Parent of every object. Not required explicitly, but added for completeness sake.
  • posixAccount: Specifies that accounts may login on unix machines.
  • shadowAccount: Enables account to be used for PAM authentication.
  • organizationalPerson: Enables account to be used as member of organizatzion.
  • inetOrgPerson: Modernized organizationalPerson (RFC2798)

uidNumbers are to be set incrementally and not re-used if someone is deleted from the ldap services database. gidNumbers are to be set equal to the uidNumber.

Password storage

According to RFC4519, passwords must be stored clear-text (which is was MS-AD does) to provide functionality like Digest-auths and Radius servers. We store passwords as hashes, which is a direct violation of the RFC, but the most sane setup for a ldap server in the 2020s.

Openldap provides a module which enables password storage using the argon2 hashing algorithm. The ldap-server is configured to generate passwords with argon2i if a LDAPv3 password change is issued. Please do not manually set the userPassword field unless you know what you are doing!. We do not store NT-Passwords to avoid the security penalty. The following changes set the password algorythm to argon2:

dn: olcDatabase={1}frontend,cn=config
changetype: modify
replace: olcPasswordHash
olcPasswordHash: {ARGON2}

For this to work you need to have the argon2 module loaded. If you already have a password policy in cn=config, delete it as it will override the algorithm stored inside the frontend database. The policy needs to be stored indise the frontend database or the server will refuse to start due to the argon module loading after the cn=config database.

If you MUST change a password manually for whatever reason, generate an argon2 hash using read -s | argon2 (openssl rand -base64 30) -e.

Users are allowed to change their own passwords to be more self-servicable. The below ACL allows them to do so.

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: to attrs=userPassword by self write by anonymous auth by dn.base="cn=admin,dc=it-syndikat,dc=org" write by * none

add: olcAccess
olcAccess: to * by self write by dn.base="cn=admin,dc=itsyndikat,dc=org" write by * read

The following is an example user creation entry inserted via the command ldapadd -x -D "cn=admin,dc=it-syndikat,dc=org" -W -f 1000-tyrolyean.ldif:

dn: uid=tyrolyean,ou=users,dc=it-syndikat,dc=org
objectClass: top
objectClass: posixAccount
objectClass: shadowAccount
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: tyrolyean
uid: tyrolyean
displayName: Daniel Plank
sn: Plank
givenName: Daniel
initials: DP
mail: tyrolyean@semi-professional.net
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/tyrolyean
loginShell: /bin/bash
gecos: tyrolyean
userPassword: {crypt}x
shadowLastChange: 0
shadowMax: 0
shadowWarning: 0

Replication

This is in here for historic reasons. We currently do not have a replication server. But in case we ever get one again, this is how one would have set it up.

Secondary and primary ldap server synchronize via pulling from the secondary ldap server. It doesn't matter onto which server which action is performed, everything will be 2-way synced and merged. Primary has a user cn=replicator,dc=it-syndikat,dc=org which is:

dn: cn=replicator,dc=it-syndikat,dc=org
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: replicator
description: Replication user
userPassword: {CRYPT}x

allowed to sync via ACL:

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to *
  by dn.exact="cn=replicator,dc=it-syndikat,dc=org" read
  by * break
-
add: olcLimits
olcLimits: dn.exact="cn=replicator,dc=it-syndikat,dc=org"
  time.soft=unlimited time.hard=unlimited
  size.soft=unlimited size.hard=unlimited

SSL

Both secondary and primary LDAP servers get their TLS certificates from letsencrypt. A script in /usr/local/bin/update_oldap.fish should be run as a post-hook to merge the certificate with letsencrypts root certificate into a chain openldap accepts.

Useful commands

Change a user password

ldappasswd -vW -D "cn=admin,dc=it-syndikat,dc=org" -S "uid=<username>,ou=users,dc=it-syndikat,dc=org"

Search its ldap tree

ldapsearch -x -D "cn=admin,dc=it-syndikat,dc=org" -W -b "dc=it-syndikat,dc=org"

User self service documentation

Password test

ldapwhoami -vvv -H "ldaps://ldap.it-syndikat.org" -D "uid=<username>,ou=users,dc=it-syndikat,dc=org" -xW

Change password

ldappasswd -vvH "ldaps://ldap.it-syndikat.org" -SWD "uid=<username>,ou=users,dc=it-syndikat,dc=org" "uid=<username>,ou=users,dc=it-syndikat,dc=org"

Query users

ldapsearch -D "uid=<username>,ou=users,dc=it-syndikat,dc=org" -W -vvv -H "ldaps://ldap.it-syndikat.org" -b"dc=it-syndikat,dc=org"

Change email (or anything else)

create change.ldif file with contents:

dn: uid=<username>,ou=users,dc=it-syndikat,dc=org
changetype: modify
replace: mail
mail: <your>@<email>

change with: ldapmodify -vvH "ldaps://ldap.it-syndikat.org" -WD "uid=<username>,ou=users,dc=it-syndikat,dc=org" -f change.ldif

Use ldapvi to edit entries

ldapvi --host ldaps://ldap.it-syndikat.org -b "dc=it-syndikat,dc=org" -D "uid=<username>,ou=users,dc=it-syndikat,dc=org"

Privacy

User-data scraping is allowed for all IP-Based authenticated users (exluding sensitive information like mail address) to allow PAM based authentication (because pam does not want to bind using the user that is authenticating...).