PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Kerberos: Probleme mit ktelnet



serm1501
10.03.08, 16:29
Hallo,

ich habe folgendes Problem:
in meinem Netz läuft ein Kerberos-Server (KDC) unter Linux SuSE 10.3 und zwei Clients auch Linux SuSE 10.3. Auf dem Rechner1 läuft ein ktelnet-Server und ktelnet-Client, auf dem Rechner2 läuft ein ktelnet-Client. Bei der Anmeldung von Rechner1 auf Rechner2 per ktelnet wird ein Passwort verlangt! Bei der Anmeldung von Rechner1 auf Rechner1 nicht, d.h. das die Authentifizierung ueber Kerberos funktionert hat. Wieso geht das nicht von einem Rechner auf einen anderen? (Bei ssh habe ich genau das gleiche Problem).
Fuer beide Rechner sind Host-Prinzipale vorhanden, bei beiden benutze ich die kerberisierte Form von telnet.

Hat jemand eine Idee?
Ueber jede Hilfe wuerde ich mich freuen.

Sonja

hessijens
11.03.08, 17:42
Flasche Systemzeit vielleicht? Einfach mal so ins Blaue getippt.

serm1501
12.03.08, 09:55
Danke fuer die Antwort,

die Systemzeit ist es leider nicht, die laufen alle synchron (so gut es geht auf VirtuellenMachines, aber fuer Kerberos reicht es).

Dafuer hat sich im Zusammenhang mit meinem LDAP-Server ein weiteres Problem ergeben:
obwohl ich ein Ticket fuer den Nutzer bekommen habe, kommt bei der Eingabe von ldapwhoami oder ldapsearch immer folgende Fehlermeldung:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL (-13): user not found: no secret in database.

Kann jemand mit dieser Fehlermeldung etwas anfangen?

Alle sasl-Pakete sind installiert, der LDAP-Server ist ein Kerberos - Client. Sowohl der Host wie auch der ldap-Dienst sind als Prinzipals mit entsprechender keytab angelegt.
Ich stehe wirklich vor einem Raetzel.

Freue mich ueber jeden Vorschlag.

hessijens
12.03.08, 15:16
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL (-13): user not found: no secret in database.


Bedeutet, das er den Kerberosuser im LDAP nicht finden kann. Bei Kerberos ist es so, dass sich sowohl Server als auch Client authentizieren müssen. Ich gehe davon aus:

Das du mit kinit oder pam_krb ein Ticket beim Einloggen bekommst? Was sagt "klist"?

Desweiteren hast Du für openldap einen KEY ldap/ldap.mydomain.org@REALM.ORG in einer KEYTAB für Openldap (ldap.mydomain.org und REALM.ORG bitte entsprechent setzen). Nimm nicht /etc/krb5.keytab, die darf nur root lesen, aber openldap läuft mit dem user ldap. Diese Key dienst der Authorisierung des openldap-servers gegenüber dem User. Bei opesuse kann man irgendwo in /etc/sysconfig/openldap oder so die Keytab für openldap angeben. Allgemein wird dazu die Variable KTNAME gesetzt, die auf den zu verwendende Ketytabfile zeigt.

Außerdem muss Du mittels "saslregexp" die Verbindung zwischen ldap user und kerberos user in /etc/openldap/slapd.conf herstellen. Das könnte z.B.: so aussehen:

saslRegexp uid=([^,]*),cn=GSSAPI,cn=auth uid=$1,ou=users,dc=mydomain,dc=org


"use not found" deutet auf einen Fehler in dieser Zuweisung hin. Dann solltest du aber nach:

ldapwhoami -Y GSSAPI
ein Ticket wie ldap/ldap.mydomain.org@REALM.ORG bekommen haben.

Wenn Du:

kdestroy
kinit
ldapwhoami -Y GSSAPI


ausführst, was sagt dann klist? Übrigens Deine slapd.conf wäre zur Fehlersuche schon ziemlich wichtig.

P.S.: Bist Du Dir sicher, das die Systemzeit stimmt? Wenn ein Computer mit GMT die anderen aber mit Localzeit laufen haben wir in Deutschland eine Stunde Unterschied. Das wäre zu viel für Kerberos, der unter SUSE Standart glaube ich nur 5 Minuten akzeptiert. Ich hatte dieses Problem schon mal.
Bei ssh im Zusammenhang mit FreeBSD habe ich außerdem das Phänomän, das "ssh meincomputer" nicht geht, "ssh meincomputer.mydomaine.org" geht aber mit Kerberos.

serm1501
12.03.08, 16:42
Hallo hessijens,

vielen Dank erstmal fuer Deine schnelle und umfangreiche Antwort.

Desweiteren hast Du für openldap einen KEY ldap/ldap.mydomain.org@REALM.ORG in einer KEYTAB für Openldap (ldap.mydomain.org und REALM.ORG bitte entsprechent setzen). Nimm nicht /etc/krb5.keytab, die darf nur root lesen, aber openldap läuft mit dem user ldap. Diese Key dienst der Authorisierung des openldap-servers gegenüber dem User. Bei opesuse kann man irgendwo in /etc/sysconfig/openldap oder so die Keytab für openldap angeben. Allgemein wird dazu die Variable KTNAME gesetzt, die auf den zu verwendende Ketytabfile zeigt.

Die KTNAME in der /etc/sysconfig/ldap habe ich gesetzt. Zu diesem Thema habe ich verschiedene Hinweise gefunden, einmal soll ich sie in der /etc/sysconfig/ldap, eine andere Quelle schreibt sie gehoert in die /etc/sysconfig/openldap. Wieder andere sagen, dort gehoert folgende Variable rein: OPENLDAP_KRB5_KEYTAB="/etc/openldap/ldap.keytab"


Außerdem muss Du mittels "saslregexp" die Verbindung zwischen ldap user und kerberos user in /etc/openldap/slapd.conf herstellen. Das könnte z.B.: so aussehen:

saslRegexp uid=([^,]*),cn=GSSAPI,cn=auth uid=$1,ou=users,dc=mydomain,dc=org


Das habe ich gemacht und meine vorherige sasl-regexp auskommentiert (siehe unten).


"use not found" deutet auf einen Fehler in dieser Zuweisung hin. Dann solltest du aber nach:

ldapwhoami -Y GSSAPI
ein Ticket wie ldap/ldap.mydomain.org@REALM.ORG bekommen haben.

Wenn Du:

kdestroy
kinit
ldapwhoami -Y GSSAPI


ausführst, was sagt dann klist?

krbtgt/MYTHOS-NETZ.LOCAL@MYTHOS-NETZ.LOCAL
ldap/hera.mythos-netz.local@MYTHOS-NETZ.LOCAL

(mythos-netz.local ist meine Testdomain, hera mein ldap-Server)

Leider führt ein ldapwhoami -Y GSSAPI zu folgender Fehlermeldung:

ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80)
additional info: SASL (-1) generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No principal in keytab matches desired name)

Ein reines ldapwhoami führt weiterhin zur gleichen Fehlermeldung:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL (-13): user not found: no secret in database.

Übrigens Deine slapd.conf wäre zur Fehlersuche schon ziemlich wichtig.

Ja, Du hast Recht, hier ist sie:

#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.

################################################## ############
#Globaler Abschnitt
################################################## ############


#Schemata laden
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/rfc2307bis.schema
include /etc/openldap/schema/yast.schema
#Hinzufuegen des nis.schema, 30.1.08
#include /etc/openldap/schema/nis.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org


#Protokolloption
#Hinzufuegen der Zeile loglevel, 30.1.08
loglevel 0
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args

# Load dynamic backend modules:
modulepath /usr/lib/openldap/modules
# moduleload back_ldap.la
# moduleload back_meta.la
# moduleload back_monitor.la
# moduleload back_perl.la


#TLS-Optionen hinzugefuegt und auskommentiert, 30.1.08

#Server Certificates
#TLSCertificateFile /etc/openldap/ssl/sldap-cert.crt
#TLSCertificateKeyFile /etc/openldap/ssl/sldap-key.pem

#TLS Security Level
#TLSCipherSuite HIGH


#Hinzufuegen von password-hash, 30.1.08
#Hashing-Methode fuer gespeicherte Passwoerter ({SSH} ist default)
password-hash {SSHA}

#Standard-Zugangsberechtigung
#default -> read
#search -> suchen erlaubt
#defaultaccess search


# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64


################################################## ############
# Nutzer und zugehoerige Zugriffsrechte
################################################## ############


# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access to user password
# Allow anonymous users to authenticate
# Allow read access to everything else
# Directives needed to implement policy:

access to dn.base=""
by * read

access to dn.base="cn=Subschema"
by * read

access to attrs=userPassword
by self write
by * auth

#access to attrs=shadowLastChange
# by self write
# by * read

access to *
by * read

# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!


################################################## #####################
# BDB database definitions
################################################## #####################

database bdb
suffix "dc=mythos-netz,dc=local"

checkpoint 1024 5
cachesize 10000

rootdn "cn=Manager,dc=mythos-netz,dc=local"
rootpw secret

# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain
index objectClass eq



################################################## #####################
# SASL Configuration for Kerberos authentication
################################################## #####################

sasl-host kdc.mythos-netz.local

sasl-realm MYTHOS-NETZ.LOCAL

#sasl-regexp
# uid=Manager,cn=mythos-netz.local,cn=gssapi,cn=auth
# cn=Manager,dc=mythos-netz,dc=local

sasl-regexp
uid=([^,]*),cn=GSSAPI,cn=auth uid=$1,ou=people,dc=mythos-netz,dc=local


P.S.: Bist Du Dir sicher, das die Systemzeit stimmt? Wenn ein Computer mit GMT die anderen aber mit Localzeit laufen haben wir in Deutschland eine Stunde Unterschied. Das wäre zu viel für Kerberos, der unter SUSE Standart glaube ich nur 5 Minuten akzeptiert. Ich hatte dieses Problem schon mal.

Bei mir laeuft ein NTP-Server und die virtuellen Machines bekommen per Cronjob ein ntpdate NTP-Server, so das die Zeit selten mehr als 2 Minuten auseinanderliegt.

Bei ssh im Zusammenhang mit FreeBSD habe ich außerdem das Phänomän, das "ssh meincomputer" nicht geht, "ssh meincomputer.mydomaine.org" geht aber mit Kerberos.[/QUOTE]

Geht bei mir leider auch nicht.

Viele Gruesse,
Sonja

hessijens
12.03.08, 17:57
OPENLDAP_KRB5_KEYTAB="/etc/openldap/ldap.keytab"
ist bei SUSE natürlich völlig richtig. Mit dieser Variable setzt /etc/init.d/ldap dann die KTNAME Variable. Jetzt wo ich es sehe erinnere ich mich.

"sasl-host kdc.mythos-netz.local" in slapd.conf hingegen ist nur dann richtig wenn dies auch Dein ldap Server hera.mythos-netz.local ist, aber selbst dann glaube ich müssen die Namen identisch sein.


sasl-host hera.mythos-netz.local

und sasl-realm habe ich nicht gesetzt, sollte aber hier so nichts schaden.

Ansonsten prüfe nochmal ob /etc/openldap/ldap.key auch dem Benutzer ldap gehört und dieser die Datei lesen darf.

serm1501
12.03.08, 18:20
Danke fuer Deine weiteren Vorschlaege.

"sasl-host kdc.mythos-netz.local" in slapd.conf hingegen ist nur dann richtig wenn dies auch Dein ldap Server hera.mythos-netz.local ist, aber selbst dann glaube ich müssen die Namen identisch sein.

Mein KDC heisst wirklich kdc und mein ldap-Server heisst hera und beides sind verschiedene Rechner, da ich gelesen habe, das der KDC möglichst keine weiteren Dienste laufen haben soll (eine Art gehaertetes System).
Muss als sasl-host der LDAP-Server oder der KDC stehen?



sasl-host hera.mythos-netz.local

und sasl-realm habe ich nicht gesetzt, sollte aber hier so nichts schaden.

Ansonsten prüfe nochmal ob /etc/openldap/ldap.key auch dem Benutzer ldap gehört und dieser die Datei lesen darf.[/QUOTE]

Die Datei /etc/openldap/ldap.keytab gehoert ldap.ldap.

Viele Gruesse,
Sonja

hessijens
13.03.08, 16:10
Sorry wegen der späten Antwort, aber zwischendurch muss ich auch noch arbeiten. So wie ich das sehe musst Du

sasl-host hera.mythos-netz.local

in Deine slapd.conf setzen, da der Ldap Server die Benutzer verwaltet.

Ich habe zudem "sasl-secprops minssf=0" in slapd.conf gesetzt, glaube aber dass ich dies nur brauche, da ich meine Heimdal Kerberos Datenbank im Ldap speichere. Eigentlich sollte Kerberos für eine entsprechende Verschlüsselung sorgen, aber wenn es nicht gehen sollte wäre diese Option auszuprobieren.

Noch eine Frage. Wenn Du ldapwhoami aufrufst, steht dann in der ersten Zeile

"SASL/GSSAPI authentication started"

Alles andere bedeutet, das Ldap per default nicht Kerberos verwendet und Du den Parameter "-Y GSSAPI" benutzen musst.

Übrigens den KDC auf einen extra Rechner laufen zu lassen ist sinnvoll, den wer den KDC kompromitieren kann kann auch das gesamte Netzwerk/REALM kompromitieren. Da Mit Kerberos (SUSE default) auch auf alle Interfaces hörcht und man ihn nur mit einem Firewall von der "bösen" Ausenwelt abschotten kann ist das durchaus sinnvoll diesen Computer irgendwo ohne Kontakt zur Außenwelt im Netzwerk zu plazieren.

serm1501
13.03.08, 18:09
Hallo hessijens,

Noch eine Frage. Wenn Du ldapwhoami aufrufst, steht dann in der ersten Zeile

"SASL/GSSAPI authentication started"

Nein, es kommt nach der Passwortaufforderung sofort die Fehlermeldung:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL (-13): user not found: no secret in database.

Alles andere bedeutet, das Ldap per default nicht Kerberos verwendet und Du den Parameter "-Y GSSAPI" benutzen musst.

Bei dem Aufruf ldapwhoami -Y GSSAPI, kommt die Fehlermeldung:
ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80)
additional info: SASL (-1) generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No principal in keytab matches desired name)

Hast Du zufaellig eine Idee, was damit gemeint ist.

Übrigens den KDC auf einen extra Rechner laufen zu lassen ist sinnvoll, den wer den KDC kompromitieren kann kann auch das gesamte Netzwerk/REALM kompromitieren. Da Mit Kerberos (SUSE default) auch auf alle Interfaces hörcht und man ihn nur mit einem Firewall von der "bösen" Ausenwelt abschotten kann ist das durchaus sinnvoll diesen Computer irgendwo ohne Kontakt zur Außenwelt im Netzwerk zu plazieren.[/QUOTE]

Danke dann war ich ja richtig davor :)

Weiterhin mit dankbaren Gruessen,
Sonja

hessijens
14.03.08, 09:49
So wie ich das nun sehe gibt es zwei Probleme.


ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80)
additional info: SASL (-1) generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No principal in keytab matches desired name)

Besagt, dass er keinen Keytab Eintrag für den Ldap-Server hat. Das könnte daran liegen, dass unterschiedliche Namen einmal "hera.mythos-netz.local" ein anderes mal "localhost" verwendet werden.
Ist in der Keytab der richtige Key ldap/hera.mythos-netz.local@MYTHOS-NETZ.LOCAL?
Steht in /etc/openldap/slapd.conf sasl-host hera.mythos-netz.local?
Wird in /etc/ldap bzw. /etc/openldap/ldap.conf auch wirklich hera.mythos-netz.local und nicht localhost benutzt?
Und hörcht der Ldap Server auch auf hera.mythos-netz.local?
Das ist per default zwar so kann aber in /etc/sysconfig/ldap oder openldap geändert werden. Sollte alles richtig sein vermute ich ein DNS Fehler. Nutzt Du einen DNS z.b: Bind?


ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL (-13): user not found: no secret in database

Hingegen bedeutet dass er keinen User finden kann. Liegen Deine User wirlich unter ou=people,dc=mythos-netz,dc=local?

ldapwhoami -x -D "cn=user,ou=people,dc=mythos-netz,dc=local" -w 'userpassword'

sollte auf jeden Fall funktionieren. Falls nicht geht:

ldapwhoami -x -h hera.mythos-netz.local -D "cn=user,ou=people,dc=mythos-netz,dc=local" -w 'userpassword'


Funktioniert dies stimmt etwas in Deine ldap.conf nicht!

serm1501
14.03.08, 15:50
Hallo hessijens,

zwischenzeitlich habe ich festgestellt das ich (noch) ein ganz anderes Problem habe, ich bekomme zwar ein TGT bei der Anmeldung aber fuer den Login-Prozess kein Session-Ticket. Ausserdem muss ich das Problem loesen, mit der LDAP-Datenbank zu kommunizieren, in der Form das ich keine zwei Benutzerdatenbanken verwalten muss. Diese Zusammenhaenge bin ich gerade dabei mir zu erarbeiten.
Deine Tipps werde ich auf alle Faelle pruefen und ich melde mich wieder. Es kann allerdings einige Zeit vergehen.
Meine Antwort, ob positiv oder negativ werde ich auf alle Faelle hier posten.

Nochmal danke fuer Deine Muehe.
Ich melde mich.

Viele Gruesse,
Sonja