ungleich-user/dev/ldap/seed.ldif
Sajeyks 24fe2122b4 Match the production LDAP layout from ungleich's sample entries
Sample entries from production show:
- customers live in ou=customer (singular), not ou=customers
- customers have gidNumber 10004 and staff 10002; uidNumbers are in
  the 10000s
- staff entries list organizationalPerson and person explicitly
- the servers serve ldaps:// on port 636

The app reads all of these from settings, so its behaviour is
unchanged; the customer entry it creates already matches production
attribute for attribute. The defaults and test setups were wrong:
env.sample, the Kubernetes ConfigMap (now ldaps:// without StartTLS,
gid 10004, start uid 10000), dev/env.dev and the dev LDAP seed now
mirror production. The made-up ou=groups is gone. The tests take the
customer DN and gidNumber from settings instead of hardcoding them.
2026-11-11 20:52:49 +03:00

57 lines
1.5 KiB
Text

# Mirrors the production layout (from sample entries ungleich provided):
# dc=ungleich,dc=ch with customers in ou=customer (singular) and staff in
# ou=users. Customers have gidNumber 10004, staff 10002.
# Passwords here are dev-only; slapadd stores them as given. Users created
# through the app get {SSHA} hashes.
dn: dc=ungleich,dc=ch
objectClass: top
objectClass: dcObject
objectClass: organization
o: ungleich
dc: ungleich
dn: ou=customer,dc=ungleich,dc=ch
objectClass: organizationalUnit
ou: customer
dn: ou=users,dc=ungleich,dc=ch
objectClass: organizationalUnit
ou: users
# Staff entry, shaped like production's ou=users entries
dn: uid=staff1,ou=users,dc=ungleich,dc=ch
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: posixAccount
objectClass: ldapPublicKey
uid: staff1
cn: staff1
sn: Staff
givenName: Sam
mail: staff1@example.com
uidNumber: 10000
gidNumber: 10002
homeDirectory: /home/staff1
loginShell: /bin/bash
userPassword: staffpass
sshPublicKey: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDevOnlyNotARealKeyDevOnlyNotARealKey00 staff1-dev
# Customer entry, shaped like production's ou=customer entries (and like
# what the app creates on registration)
dn: uid=customer1,ou=customer,dc=ungleich,dc=ch
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: ldapPublicKey
uid: customer1
cn: customer1
sn: Customer
givenName: Cora
displayName: Cora Customer
mail: customer1@example.com
uidNumber: 10001
gidNumber: 10004
homeDirectory: /home/customer1
loginShell: /bin/bash
userPassword: customerpass