Linux Benutzer-Authentifizierung mit dem Oracle Internet Directory

Transkript

1 Linux Benutzer-Authentifizierung mit dem Oracle Internet Directory Autor: Frank Berger DOAGNews Q4_2004 Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, bei auch nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes.

2 Die Wirtschaftlichkeit eines IT-Systems hängt unter anderem davon ab, wie gut es sich mit anderen verknüpfen lässt. Ein solcher Anknüpfungspunkt ist zum Beispiel der Zugriff auf zentrale Verzeichnisdienste. In [1] wurde beschrieben, wie sich die Benutzer-Authentifizierung von Oracle Datenbanken mit dem OID zentralisieren lässt. Im folgenden soll skizziert werden, wie sich die Authentifizierung von Linux Benutzern mit dem OID umsetzen lässt. Vorbemerkung Der Einsatz des OID in einer heterogenen Umgebung lässt sich nicht mit einem Rezept beschreiben. Deshalb kann hier nur grob ein möglicher Weg mit typischen Stolpersteinen aufgezeigt werden. An dieser Stelle auch die Warnung, die nachfolgende Konfiguration nur in einer Testumgebung zu testen! Da es um die Authentifizierung von Betriebssystem- Benutzern geht, ist es sehr wahrscheinlich, dass man sich beim Experimentieren einmal selbst aussperrt! Als Basis für diesen Artikel dienten der OracleAS 10g und RedHat Enterprise Linux 3. Ziel soll die Benutzer- Authentifizierung für SecureShell-Logins unter Linux sein. OID fitmachen Damit im OID Linux relevante Informationen wie Homeverzeichnis oder Loginshell gespeichert werden können, müssen im OID entsprechende Objektklassen vorhanden sein. Für uns sind hier die Klassen posixaccount und posixgroup von besonderer Bedeutung. Bei einer Default Installation der OracleAS 10g Infrastruktur sind diese Klassen bereits im OID enthalten. Bei anderen Versionen müssen diese evtl. von Hand nachinstalliert werden. Als nächstes benötigen wir für die Suche nach Einträgen zusätzliche Indize für die Attribute uidnumber, memberuid und gidnumber. Hierzu verwendet man den Befehl catalog.sh bei heruntergefahrenem OID. Für das Attribut uidnumber sieht das Anlegen des Index so aus: $ORACLE_HOME/ldap/bin/catalog.sh -connect $ORACLE_SID -add -attr uidnumber Darüber hinaus legen wir eine zusätzliche Gruppe ssh-users im OID an: dn: cn=ssh-users,cn=groups,dc=fm-berger,dc=de changetype: add objectclass: top objectclass: groupofuniquenames objectclass: orclgroup objectclass: posixgroup cn: ssh-users gidnumber: 5001 orclisvisible: true displayname: SSH users description: linux ssh users Wichtig ist, dass die Gruppe das Attribut gidnumber der Objektklasse posixgroup enthält. Bei Gruppen, die mit den OIDDAS angelegt wurden, ist dies standardmäßig nicht der Fall. In einer Produktivumgebung sollte man im OID für die LDAP-Anfragen der Linux Rechner einen eigenen Read-Only Benutzer anlegen, der über die entsprechenden Berechtigungen verfügt, um auch die Benutzerpasswörter abfragen zu können. Benutzerverwaltung mit den OIDDAS übers Web Die Benutzerverwaltung lässt sich über das Web mit den OID Delegated Administration Services erledigen. Hierzu sind nachfolgende Anpassungen erforderlich: Als Administrator (orcladmin) meldet man sich bei den OIDDAS via Web an Die Einstellungen können dann über den Punkt Configuration->User Entry vorgenommen werden Hier müssen zunächst die Objektklassen posixaccount und posixgroup hinzugefügt werden Mit den dazugehörigen Attributen uidnumber, gidnumber, homedirectory und loginshell wird auf der nächsten Webseite genauso verfahren Zusätzlich lassen sich diese Attribute mittels einer Kategorie (z.b. Linux Login) gruppieren.

3 Danach können mit den OIDDAS Linux Benutzer angelegt und zur Gruppe ssh-users hinzugefügt werden. Die Eingabe der Benutzerdaten ist in dieser Form leider noch etwas spartanisch. NSS und PAM unter Linux Die Grundlage der Authentifizierung von Benutzern unter Linux bilden NSS (Name Service Switch) und PAM (Pluggable Authentication Module). Für die Integration mit dem OID sind folgende RPM-Pakete wichtig: openssl-0.9.7a-33.4.rpm, pam rpm, openldap rpm, nss_ldap rpm Die Konfiguration der Anbindung erfolgt dann über die Datei /etc/ldap.conf: host s0002.fm-berger.de ldap_version 3 base cn=users,dc=fm-berger,dc=de binddn cn=pamreader,cn=users,dc=fm-berger,dc=de bindpw secret pam_password_prohibit_message to change your password nss_base_group cn=groups,dc=fm-berger,dc=de uri ldap://s0002.fm-berger.de:389/ port 389 Damit die Informationen im OID auch vom NSS verwendet werden, muss die Datei /etc/nsswitch.conf noch wie folgt angepasst werden: passwd: shadow: group: Nun lässt sich das Zusammenspiel Linux OID auch sofort mit dem Befehl id unter Linux überprüfen: [frank@w0010 etc]# id oiduser uid=5000(oiduser) gid=5001(ssh-users) groups=5002(smb-users) NSS hat also über LDAP die Daten des Benutzers oiduser aufgelöst. Für die Aktivierung des SecureShell-Zugang der OID-Benutzer könnte folgende PAM Konfiguration in /etc/pam.d/sshd dienen: auth required pam_nologin.so auth sufficient pam_ldap.so auth required pam_unix_auth.so try_first_pass account sufficient pam_ldap.so account required pam_unix_acct.so password optional password required password required pam_ldap.so pam_cracklib.so pam_pwdb.so use_first_pass session required pam_unix_session.so session sufficient pam_mkhomedir.so skel=/etc/skel/ umask=0077 Zusätzlich muss die Konfiguration des SecureShell-Daemon (/etc/ssh/sshd_config) noch um die Einträge: PAMAuthenticationViaKbdInt yes PermitRootLogin no ergänzt werden.

4 Damit für neue Benutzer beim ersten Login das Homeverzeichnis mit pam_mkhomedir erstellt werden kann, muss das darüber liegende Verzeichnis (/home) auf world-writeable gesetzt sein oder der SecureShell-Daemon wird mit der Option UsePrivilegeSeparation no konfiguriert. Beide Lösungen sind unter Sicherheitsaspekten allerdings nicht optimal. Ein letzter wichtiger Punkt sei an dieser Stelle noch erwähnt: Benutzer, denen im OID keine uidnumber zugewiesen wurde, hatten bei meinen Versuchen automatisch die uid=0. Wenn man hier nicht aufpasst und entsprechende Vorkehrungen trifft, hat man unfreiwilligerweise mit vielen neuen root Benutzern zu kämpfen. Selektion mit Gruppen und pam_require Welche Dienste ein Benutzer in Anspruch (z.b. Portal aber kein Linux Zugriff) nehmen darf, wird im OID über die Zugehörigkeit einer Gruppe gesteuert. Um dieses Konzept auch mit PAM nutzen zu können, gibt es in ldap.conf einen entsprechenden Parameter pam_groupdn, mit dem sich eine Gruppe benennen lässt. Damit dies aber greift, muss der account Eintrag von pam_ldap von sufficient auf required gesetzt werden. Mit dieser Einstellung verliert man jedoch die Fallback Möglichkeit einer Authentifizierung über lokale Benutzer. Zudem ist der Eintrag pam_groupdn für alle Dienste, die PAM nutzen, gleich. Eine feinkörnige Selektion ist nicht möglich. Abhilfe schafft hier das Module pam_require. Damit lässt sich die Beschränkung von Diensten auf einzelne Gruppen sehr leicht umsetzen. Für unsere Gruppe ssh-users könnte dies z.b. so aussehen: account Leider ist pam_require noch nicht im Standardumfang von PAM-Linux enthalten; kann aber kostenlos von [2] heruntergeladen werden. Aber sicher! Mit SSL Hierfür ist leider etwas mehr Konfigurationsarbeit notwendig. Zunächst ist im OID ein eigenes Configuration-Set mit SSL Server-Authentication einzurichten. In [3] wird auf den OTN-Seiten sehr ausführlich beschrieben, wie man dies umsetzt. Auf der Seite von Linux sind in /etc/ldap.conf folgende Erweiterungen erforderlich: uri ldaps://s0002.fm-berger.de:4055/ port 4055 ssl on tls_checkpeer no tls_reqcert allow tls_cacertfile /etc/ssl/certs/oid-cacert.pem tls_ciphers SSLv3 In /etc/ssl/certs/oid-cacert.pem speichert man das Root-Zertifikat, das zum Signieren des OID-Server Zertifikates verwendet wurde. Leider hat sich in der Praxis herausgestellt, dass es auf Linux-Systemen mit OpenSSL ab der Version 0.9.6d und höher Probleme mit dem Verbindungsaufbau zum OID über SSL gibt. Schuld daran ist ein Security Fix, der mit dieser OpenSSL Version eingeführt wurde. Betroffen davon ist insbesondere auch das RedHat Enterprise Linux Version 3. Um dieses Problem zu beheben, habe ich einen Patch [4] für OpenLDAP geschrieben, der den Security Fix in Verbindung mit LDAPS deaktiviert. Fazit Die hier beschriebene Integration von PAM-Linux und dem OID ist nur als erster Schritt zu verstehen. Es gibt hier sicherlich noch viel Raum für Verbesserungen. Sowohl PAM als auch OID haben zudem noch wesentlich mehr zu bieten. Darum ist es eigentlich sehr schade, dass man in Veröffentlichungen zum Thema LDAP nur selten vom Oracle Internet Directory liest.

5 Referenzen / Links [1] DOAGNews Q3/2003, Sven Vetter Zentrale Benutzerverwaltung [2] splitbrain.org, pam_require, [3] OTN, Getting Started with Oracle Internet Directory, [4] RedHat Bugzilla, openldap can't connect to OID- Oracle Internet Directory using ldaps, Frank Berger Bergstraße 22 D Burtenbach frank.berger@fm-berger.de Internet: