LDAP na Ubuntu 18.04, obiekty posixAccount: Jak dodać atrybuty karty dostępu i e-mail?

_jta_ napisał:

(...) akiś automat, może nie będzie zły - mamy tu przecież ElektrodaBot-a...

@ElektrodaBot - jak powinno być zrobione dodawanie atrybutów do struktury konta użytkownika w LDAP zrobionej według standardu POSIX (posixAccount), używającego serwera "slapd", aby było to zgodne ze standardami przyjętymi dla LDAP?

Bezpośrednia odpowiedź na pytanie
Aby dodać niestandardowe atrybuty do konta użytkownika w LDAP, korzystającego ze standardu POSIX (posixAccount) i serwera slapd, należy stworzyć lub rozszerzyć odpowiedni schemat (w pliku .schema lub w formacie .ldif), a następnie użyć go w konfiguracji serwera OpenLDAP. Zaleca się unikanie bezpośredniej modyfikacji istniejącej klasy posixAccount na rzecz dodania własnej klasy obiektów (najczęściej typu AUXILIARY) albo wykorzystania innej standardowej klasy zawierającej już potrzebne atrybuty. W ten sposób zachowuje się zgodność z przyjętymi standardami LDAP (RFC 2307) i nie narusza integralności schematu.

Kluczowe punkty:
- Nie należy bezpośrednio ingerować w definicję posixAccount.
- Należy zdefiniować własne atrybuty i/lub obiekty w ramach rozszerzonego schematu (z unikalnym OID).
- Zmiany wprowadza się do serwera LDAP poprzez odpowiednio sformatowane pliki .ldif i narzędzia typu ldapmodify.

Szczegółowa analiza problemu

1. Podstawy standardu posixAccount
Klasa obiektów posixAccount, zdefiniowana w RFC 2307, służy do reprezentowania użytkownika w systemie POSIX. Wymaga ona określonych atrybutów (m.in. uid, uidNumber, gidNumber, homeDirectory), które umożliwiają logowanie do systemów uniksowych z wykorzystaniem LDAP jako centralnego repozytorium danych o użytkownikach.

2. Standardowe atrybuty i ich rozszerzanie
Standardowa posixAccount zapewnia podstawowe informacje konieczne dla uwierzytelniania i autoryzacji w systemie bazującym na plikach passwd/grupy przeniesionych do LDAP. Jeśli potrzebujemy nowych atrybutów, które nie występują w istniejących schematach (np. employeeNumber, czy dowolny atrybut firmowy), powinniśmy:

1. Sprawdzić, czy nie istnieje już standardowa klasa obiektu bądź atrybut o pożądanej funkcjonalności (np. inetOrgPerson, organizationalPerson).
2. Jeśli w standardowych schematach nie ma odpowiednich atrybutów, zdefiniować je samodzielnie, przydzielając im unikalny OID i tworząc własną klasę obiektów bądź uzupełniając istniejącą klasę AUXILIARY.

3. Definiowanie nowego schematu (przykład)
Najczęściej definiuje się niestandardowe atrybuty i klasę obiektu w pliku .schema lub .ldif. Na przykład:

• Definicja atrybutu:
attributetype ( 1.3.6.1.4.1.99999.1.1
NAME 'myCustomAttribute'
DESC 'Przykładowy atrybut niestandardowy'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )

• Definicja klasy obiektu:
objectclass ( 1.3.6.1.4.1.99999.2.1
NAME 'myCustomPosixExtension'
DESC 'Rozszerzenie klasy posixAccount'
SUP posixAccount
MAY ( myCustomAttribute ) )

Oczywiście można też zastosować AUXILIARY zamiast SUP posixAccount, jeśli nie chcemy wprowadzać kolizji w definicji obiektu.

4. Załadowanie nowego schematu do slapd
W zależności od wersji OpenLDAP i sposobu konfiguracji, schematy ładuje się:

- Poprzez zmodyfikowanie plików w katalogu schema/ (starsze wersje slapd).
- W trybie dynamicznej konfiguracji (cn=config) za pomocą pliku .ldif i narzędzia ldapadd / ldapmodify (zalecany w nowszych wersjach).

Przykład pliku .ldif do wgrania schematu:

dn: cn=myCustomSchema,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: myCustomSchema
olcAttributeTypes: ( 1.3.6.1.4.1.99999.1.1 NAME 'myCustomAttribute' ... )
olcObjectClasses: ( 1.3.6.1.4.1.99999.2.1 NAME 'myCustomPosixExtension' ... )

Następnie ładujemy do serwera:
ldapadd -Y EXTERNAL -H ldapi:/// -f myCustomSchema.ldif

5. Przykładowe dodanie atrybutu do konta
Gdy nowy schemat jest aktywny w slapd, możemy dodać atrybut do użytkownika:

dn: uid=jnowak,ou=people,dc=example,dc=com
changetype: modify
add: objectClass
objectClass: myCustomPosixExtension
-
add: myCustomAttribute
myCustomAttribute: Wartość niestandardowa

Operację tę wykonujemy poleceniem:
ldapmodify -x -D "cn=admin,dc=example,dc=com" -W -f modify-user.ldif

6. Najlepsze praktyki
- Stosować unikalny zakres OID. Rejestrowanie OID w IANA lub korzystanie z puli prywatnej minimalizuje ryzyko konfliktu.
- Jeśli to możliwe, korzystać z gotowych i sprawdzonych klas obiektów (np. inetOrgPerson) zamiast definiować wszystko od zera.
- Pilnować unikalności uidNumber i gidNumber (posixowe ID). W większych środowiskach konieczne jest centralne zarządzanie pulą ID.
- Rozważyć uwierzytelnianie i szyfrowanie (TLS/SSL) oraz ścisłe kontrolowanie, kto ma prawo modyfikować katalog LDAP.

Pytania do użytkownika
- Jakie konkretnie atrybuty chcesz dodać do rekordów posixAccount?
- Czy masz już włączoną dynamiczną konfigurację (cn=config) w slapd, czy korzystasz ze starszego stylu plików konfiguracyjnych i plików .schema?
- Czy posiadasz mechanizm zapewniający unikalność uidNumber i gidNumber u użytkowników (np. skrypt centralny)?

Jeżeli potrzebujesz dalszych informacji, np. szczegółowego przykładu definicji .ldif dla swojego atrybutu, to daj znać. Chętnie pomogę w bardziej szczegółowej konfiguracji!