UMC - Authentisierungsfehler: Authentisierung fehlgeschlagen

UCS - Univention Corporate Server
#1

Hallo,

habe ein UCS 2.4-1 64Bit als dom0 (UCS Master) und darauf ebenfalls ein UCS 2.4-1 64Bit als domU laufen (UCS Slave). Der Join-Vorgang beim Slave lief erfolgreich durch und auf beiden Seiten wurde ein Update durchgeführt.

Wenn ich nun via Browser auf den domU (UCS Slave) gehe und mich im UMC anmelde, kommt folgender Fehler:

Authentisierungsfehler: Authentisierung fehlgeschlagen

in management-console-web.log steht:

29.03.11 13:08:04 DEBUG_INIT 29.03.11 13:08:04 ADMIN ( ERROR ) : univention-console-frontend.py: specified locale is not available (cmdline: de) UNIVENTION_DEBUG_BEGIN : uldap.__open host=mailsrv.koller.local port=389 base=dc=koller,dc=local UNIVENTION_DEBUG_END : uldap.__open host=mailsrv.koller.local port=389 base=dc=koller,dc=local UNIVENTION_DEBUG_BEGIN : uldap.__open host=mastersrv.koller.local port=389 base=dc=koller,dc=local UNIVENTION_DEBUG_END : uldap.__open host=mastersrv.koller.local port=389 base=dc=koller,dc=local 29.03.11 13:08:05 ADMIN ( WARN ) : univention-console-frontend.py: sock: new connection 29.03.11 13:08:10 ADMIN ( WARN ) : univention-console-frontend.py: sock: new connection

in management-console-server.log steht:

29.03.11 13:08:11  ADMIN       ( ERROR   ) : PAM: authentication error: ('Benutzer bei zu Grunde liegendem Authentifizierungsmodul nicht bekannt', 10)

Was bedeutet “specified locale is not available (cmdline: de)”??

Wenn ich ein

ucr search locale

ausführe, bekomme ich auf beiden Servern die gleiche Ausgabe:

[code]root@mailsrv:/var/log/univention# ucr search locale
locale/default: de_DE.UTF-8:UTF-8
Default localisation (Interface language, character sets, etc.)

locale/keymap: de-latin1
Keyboard layout

locale: de_DE.UTF-8:UTF-8
Installed localisation data (Interface language, character sets, etc.)[/code]

Danke schon mal!

PS: wenn Sie möchten, können Sie sich via TeamViewer auf den Server verbinden.

mfg
Daniel

#2

Hallo,

können Sie sich auf der Kommandozeile des DC Slave per Administrator anmelden?
Falls ja, können Sie für den Benutzer Administrator ein Kerberos Ticket holen:

# kinit Administrator

Läuft der Apache Web-Server?

# ps waux | grep "apache"

Laufen evtl. weitere UMC Prozesse die den Anmeldevorgang blockieren?

# ps waux | grep "univention-management-console-server"

Zusätzlich wäre es hilfreich wenn Sie einmal die Punkte in dem folgenden SDB-Artikel ausführen und die Ergebnisse prüfen: sdb.univention.de/1173

Mit freundlichen Grüße
Murat Odabas

#3

Kerberos:

root@mailsrv:~# kinit Administrator Administrator@KOLLER.LOCAL's Password: kinit: krb5_get_init_creds: Client (Administrator@KOLLER.LOCAL) unknown

Apache:

root@mailsrv:~# ps waux | grep "apache" root 3518 0.0 1.2 198052 12972 ? Ss 12:56 0:00 /usr/sbin/apache2 -k start www-data 3561 0.0 0.5 198052 5272 ? S 12:56 0:00 /usr/sbin/apache2 -k start www-data 3562 0.0 0.5 198052 5276 ? S 12:56 0:00 /usr/sbin/apache2 -k start www-data 3563 0.0 0.5 198052 5272 ? S 12:56 0:00 /usr/sbin/apache2 -k start www-data 3564 0.0 0.5 198052 5272 ? S 12:56 0:00 /usr/sbin/apache2 -k start www-data 3565 0.0 0.5 198052 5272 ? S 12:56 0:00 /usr/sbin/apache2 -k start root 3761 0.0 0.0 5176 784 pts/0 D+ 12:57 0:00 grep apache root@mailsrv:~#

UMC-Prozesse:

root@mailsrv:~# ps waux | grep "univention-management-console-server" root 2601 0.0 0.0 112 32 ? Ss 12:56 0:00 runsv univention-management-console-server root 3186 0.2 2.8 193444 28860 ? S 12:56 0:00 /usr/bin/python2.4 /usr/sbin/univention-management-console-server -n -d 1 -l de_DE.UTF-8 root 3778 0.0 0.0 7240 848 pts/0 S+ 12:59 0:00 grep univention-management-console-server root@mailsrv:~#

Beim Boot ist mir folgender Fehler aufgefallen (siehe Screenshot) -> was bedeuten die Fehler genau?

mfg
Daniel

#4

Hallo,

habe nun den Slave neu aufgesetzt (UCS 2.4 64bit), univention-updater und univention-join ausgeführt. Soweit lief alles sauber durch, nur tritt der gleiche Fehler wie davor auf -> Authentisierungsfehler: Authentisierung fehlgeschlagen (beim Anmelden an UMC)

mfg
Daniel

#5

weitere Infos bezüglich SDB 1173:

Läuft der UMC-Server:

root@mailsrv:~# ps waux | grep univention-management-console-server root 2179 0.0 0.0 7236 828 pts/0 S+ 09:55 0:00 grep univention-management-console-server root 2545 0.0 0.0 112 28 ? Ss Mar30 0:00 runsv univention-management-console-server root 2861 0.0 0.6 193348 28780 ? S Mar30 0:00 /usr/bin/python2.4 /usr/sbin/univention-management-console-server -n -d 1 -l de_DE.UTF-

Läuft der LDAP-Server (auf DC-Master, DC-Backup, DC-Slave)

[code]root@mailsrv:~# ldapsearch -x -ZZZ -s base -h $hostname.$domainname

extended LDIF

LDAPv3

base <dc=koller,dc=local> (default) with scope baseObject

filter: (objectclass=*)

requesting: ALL

koller.local

dn: dc=koller,dc=local
objectClass: top
objectClass: krb5Realm
objectClass: univentionPolicyReference
objectClass: nisDomainObject
objectClass: domainRelatedObject
objectClass: domain
objectClass: univentionBase
objectClass: univentionMailDomain
krb5RealmName: KOLLER.LOCAL
associatedDomain: koller.local
dc: koller
nisDomain: koller.local
mailRelay: mailsrv.koller.local
univentionPolicyReference: cn=default-settings,cn=thinclient,cn=policies,dc=ko
ller,dc=local
univentionPolicyReference: cn=default-settings,cn=boot,cn=dhcp,cn=policies,dc=
koller,dc=local
univentionPolicyReference: cn=default-settings,cn=dns,cn=dhcp,cn=policies,dc=k
oller,dc=local
univentionPolicyReference: cn=default-settings,cn=routing,cn=dhcp,cn=policies,
dc=koller,dc=local
univentionPolicyReference: cn=default-settings,cn=pwhistory,cn=users,cn=polici
es,dc=koller,dc=local
univentionPolicyReference: cn=default-users,cn=admin-settings,cn=users,cn=poli
cies,dc=koller,dc=local

search result

search: 3
result: 0 Success

numResponses: 2

numEntries: 1

root@mailsrv:~# [/code]

Stimmt die Systemzeit -> ja!

Sind die SSL-Zertifikate abgelaufen

root@mailsrv:~# univention-certificate dump -name $hostname.$domainname | egrep -i -A 2 'validity' Validity Not Before: Mar 28 10:51:35 2011 GMT Not After : Mar 26 10:51:35 2016 GMT

Laufen die Univention-DNS Dienste (univention-bind und univention-bind-proxy)
-> am Master schon, am Slave natürlich nicht.

Sind korrekte Nameserver gesetzt
ja, Nameserver ist der Master.

Kann Servername zu IP und IP zu Servername korrekt aufgelöst werden -> ja:

root@mailsrv:~# host mastersrv mastersrv.koller.local has address 192.168.0.1 root@mailsrv:~# host 192.168.0.1 1.0.168.192.in-addr.arpa domain name pointer mastersrv.koller.local.

Wird der Kerberos Service-Record korrekt aufgelöst

root@mailsrv:~# host -t SRV _kerberos._tcp.$domainname _kerberos._tcp.koller.local has SRV record 0 0 88 mailsrv.koller.local. _kerberos._tcp.koller.local has SRV record 0 0 88 backupsrv.koller.local. _kerberos._tcp.koller.local has SRV record 0 0 88 mastersrv.koller.local.

Kerberos Ticket mit kinit holen

root@mailsrv:~# kinit Administrator Administrator@KOLLER.LOCAL's Password: kinit: krb5_get_init_creds: Client (Administrator@KOLLER.LOCAL) unknown root@mailsrv:~# klist klist: No ticket file: /tmp/krb5cc_0

Gibt es Hinweise in der Kerberos Log-Datei

2011-03-31T09:52:23 AS-REQ Administrator@KOLLER.LOCAL from IPv4:192.168.0.3 for krbtgt/KOLLER.LOCAL@KOLLER.LOCAL 2011-03-31T09:52:23 UNKNOWN -- Administrator@KOLLER.LOCAL: No such entry in the database 2011-03-31T09:52:23 sending 142 bytes to IPv4:192.168.0.3 2011-03-31T10:06:22 AS-REQ Administrator@KOLLER.LOCAL from IPv4:192.168.0.3 for krbtgt/KOLLER.LOCAL@KOLLER.LOCAL 2011-03-31T10:06:22 UNKNOWN -- Administrator@KOLLER.LOCAL: No such entry in the database 2011-03-31T10:06:22 sending 142 bytes to IPv4:192.168.0.3

Eine Anmeldung ohne Kerberos prüfen
-> auth wurde auskommentiert -> Anmeldung noch immer nicht möglich!

Bitte um baldige Unterstützung!

Vielen Dank!

mfg
Daniel

#6

Hallo,

Sie schrieben:

[quote]root@mailsrv:~# kinit Administrator
Administrator@KOLLER.LOCAL’s Password:
kinit: krb5_get_init_creds: Client (Administrator@KOLLER.LOCAL) unknown[/quote]

So wie es aussieht gibt es Probleme mit Kerberos. Ein Kerberos Ticket sollte bei einem gejointen System ohne Probleme erstellt werden. Können Sie für die weitere Analyse bitte die folgenden Punkte durchführen/prüfen?

  • Läuft der Kerberos Dienst?
  # ps waux | grep heimdal

  • Gibt es weitere Meldungen in der Log-Datei /var/log/heimdal-kdc.log auf dem DC Slave und DC Master?

  • Welchen Status gibt der folgende Befehl auf dem DC Slave zurück?

  # univention-check-join-status
  • Kann die Kerberos Datenbank auf dem DC Slave abgefragt werden?

# kadmin -l get Administrator@KOLLER.LOCAL

  • Was steht auf dem DC Slave in den UCR-Variablen kerberos/realm,
    kerberos/adminserver und kerberos/kdc?
  # ucr search kerberos
  • Funktioniert allgemein die Namensauflösung, wird ein externer DNS Server verwendet?

[code] # host

host [/code]

  • Sind die Uhrzeiten auf den beiden Systemen (DC Master und DC Slave) synchron?

Bzgl. den Boot-Meldungen:
Die Meldungen werden durch die Ramdisk generiert. Die Module sind in der Ramdisk nicht vorhanden und können daher nicht geladen werden. Erst im nachhinein wenn das Betriebssystem läuft und die Kontrolle übernommen hat können die entsprechenden Module geladen werden.

Für den Systembetrieb sind diese Meldungen aber nicht kritisch.

Mit freundlichen Grüßen
Murat Odabas

#7

Hallo,

  • Läuft der Kerberos Dienst?
    ->Master:

root@mastersrv:~# ps waux | grep heimdal root 4300 0.0 0.0 53124 3340 ? S Mar28 0:01 /usr/lib/heimdal-servers/kdc --config-file=/etc/heimdal-kdc/kdc.conf root 4303 0.0 0.0 57080 2572 ? S Mar28 0:00 /usr/lib/heimdal-servers/kpasswdd root 27016 0.0 0.0 7240 860 pts/1 S+ 11:37 0:00 grep heimdal
->Slave:

root@mailsrv:~# ps waux | grep heimdal root 2602 0.0 0.0 53008 2996 ? S Mar30 0:00 /usr/lib/heimdal-servers/kdc --config-file=/etc/heimdal-kdc/kdc.conf root 5310 0.0 0.0 7236 824 pts/0 S+ 11:36 0:00 grep heimdal

  • Gibt es weitere Meldungen in der Log-Datei /var/log/heimdal-kdc.log auf dem DC Slave und DC Master?
    ->Logiles wurden angehängt.

  • Welchen Status gibt der folgende Befehl auf dem DC Slave zurück?
    -> Master:

root@mastersrv:~# univention-check-join-status Joined successful
-> Slave:

root@mailsrv:~# univention-check-join-status Error: localhost ldapsearch failed

  • Kann die Kerberos Datenbank auf dem DC Slave abgefragt werden?

root@mailsrv:~# kadmin -l get Administrator@KOLLER.LOCAL kadmin: get Administrator@KOLLER.LOCAL: Principal does not exist

  • Was steht auf dem DC Slave in den UCR-Variablen kerberos/realm,
    kerberos/adminserver und kerberos/kdc?

[code]root@mailsrv:~# ucr search kerberos
kerberos/adminserver: mastersrv.koller.local
Kerberos admin server for the realm

kerberos/autostart: yes

kerberos/kdc: mailsrv
List of KDC’s for the realm

kerberos/password/quality/check: yes
Check of password strength by cracklib2 can be activated by setting this value to ‘yes’.

kerberos/realm: KOLLER.LOCAL
Kerberos realm of the domain

kerberos/v4tickets:
Activate kerberos v4 tickets

security/services/kerberos:
If this variable is set to disabled the service kerberos is blocked via Univention Firewall.[/code]

  • Funktioniert allgemein die Namensauflösung, wird ein externer DNS Server verwendet?
    -> Master:

root@mastersrv:~# host mastersrv mastersrv.koller.local has address 192.168.0.1 root@mastersrv:~# host mailsrv mailsrv.koller.local has address 192.168.0.3
-> Slave:

root@mailsrv:~# host mailsrv mailsrv.koller.local has address 192.168.0.3 root@mailsrv:~# host mastersrv mastersrv.koller.local has address 192.168.0.1

  • Sind die Uhrzeiten auf den beiden Systemen (DC Master und DC Slave) synchron?
    ja. (ntp wurde konfiguriert)

Vielen Dank!

mfg
Daniel
heimdal-kdc_slave.log (3.8 KB)
heimdal-kdc_master.log (206 KB)

#8

Hallo,

Sie schrieben:

[quote]-> Slave:
Code:
root@mailsrv:~# univention-check-join-status
Error: localhost ldapsearch failed[/quote]
Aus der Meldung ist zu ersehen das der DC Slave Join-Vorgang nicht einwandfrei durchgelaufen ist. Es kann keine Verbindung zum LDAP auf dem DC Master hergestellt werden. Aus der Log-Datei “heimdal-kdc_slave.log” des DC Slave ist außerdem auch die folgende Meldung zu ersehen:

[quote]2011-03-30T15:10:47 label: default
2011-03-30T15:10:47 dbname: ldap:dc=univention,dc=unconfigured[/quote]
Hier wird noch der Standard Wert verwendet. Die LDAP Basis sollte nach einem erfolgreichen Join auf den Wert “dc=koller,dc=local” gesetzt sein, dies ist bei Ihnen im Moment nicht der Fall. Können sie bitte den DC Slave nochmal in die Domäne Joinen und die Log-Datei /var/log/univention/join.log posten?

Mit freundlichen Grüßen
Murat Odabas

#9

Hallo,

hab den Join-Vorgang noch einmal gestartet -> Logfile wurde angehängt.

mfg
Daniel
join.log (12.6 KB)

#10

Hallo,

aus der Log-Datei ist zu entnehmen das der Rechner Account im LDAP-Container "computers "liegt: [quote]object class violation while adding cn=mailsrv,cn=computers,dc=koller,dc=local[/quote]
Da es sich bei einem Slave auch um einen DC handelt muss das Objekt im entsprechenden Container erstellt werden. Bitte löschen Sie das Slave Rechner-Objekt aus dem LDAP und erstellen einen neuen im vorgesehenen Container “computers/dc”. Joinen Sie das System anschließend erneut in die Domäne.

Mit freundlichen Grüßen
Murat Odabas

#11

Hallo,

das war’s!
Vielen Dank!

mfg
Daniel

Mastodon