8.2 KiB
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...).