Samba findet Benutzerinformationen im AD nicht

[Jürgen Leibner]

Am Montag, 19. Juni 2006 23:21 schrieb Florian Schwarz:
> Florian Schwarz schrieb:
> > Jürgen Leibner schrieb:
> >>> Am Samstag, 17. Juni 2006 16:17 schrieb Florian Schwarz:
> >>>> [...]
> Arr, nu dachte ich es funktioniert, aber pustekuchen: Von ein paar
> Clients funktionierts ohne Probleme, von anderen nicht (trotz gleichem
> OS mit gleichen Einstellungen). Beim Zugriff von einem Rechner wo es
> nicht funktioniert steht folgendes im Log:
>
> log.client:
>
> [2006/06/19 15:03:45, 1] smbd/sesssetup.c:reply_spnego_kerberos(197)
>   Failed to verify incoming ticket!
> [2006/06/19 15:03:45, 1] smbd/sesssetup.c:reply_spnego_kerberos(197)
>   Failed to verify incoming ticket!
> [2006/06/19 15:03:46, 1] smbd/sesssetup.c:reply_spnego_kerberos(197)
>   Failed to verify incoming ticket!
> [2006/06/19 15:03:46, 1] smbd/sesssetup.c:reply_spnego_kerberos(197)
>   Failed to verify incoming ticket!
> [2006/06/19 15:03:46, 1] smbd/sesssetup.c:reply_spnego_kerberos(197)
>   Failed to verify incoming ticket!
> [2006/06/19 15:03:59, 0] lib/util_sock.c:write_data(557)
> write_data: write failure in writing to client 0.0.0.0. Error Connection
> reset by peer
> [2006/06/19 15:03:59, 0] lib/util_sock.c:send_smb(765)
>   Error writing 4 bytes to client. -1. (Connection reset by peer)
> [2006/06/19 15:14:22, 0] lib/util_sock.c:write_data(557)
>   write_data: write failure in writing to client 0.0.0.0. Error
> Connection reset by peer
>
> log.smbd
>
> [2006/06/19 15:03:59, 0] lib/util_sock.c:get_peer_addr(1225)
>   getpeername failed. Error was Transport endpoint is not connected
> [2006/06/19 15:03:59, 0] lib/util_sock.c:get_peer_addr(1225)
>   getpeername failed. Error was Transport endpoint is not connected
> 
> und die log.wb-DOMAIN is voll von folgendem:
>
> [2006/06/19 15:05:01, 0] lib/util_sid.c:string_to_sid(285)
>   string_to_sid: Sid S-0-0 is not in a valid format.
>
> Was kann ich noch tun?
Einiges ;-)

Ach ja, Distri und Sambaversion sowie MS-Client-/Serverversionen mit welchen 
Service-Packs wären auch mal interessant :-)

Als erstes Samba Bugs lesen:
https://bugzilla.samba.org/show_bug.cgi?id=1717
https://bugzilla.samba.org/show_bug.cgi?id=1775
...

Demnach ist's kein Samba-ADS Problem. Das Problem scheint auf de Clientseite 
zu liegen. 
Schau mal in den Ereignisprotokollen der Clients die Probleme haben nach etwas 
wie: "Conflicting principals...." (oder in Deutsch ..., weiss ich nich ...)

Danach kannste noch:

Setz mal:
name resolve order = wins bcast

log level = 5 passdb:10 auth:10 winbind:10
log file = /var/log/samba/log.%m # Verzeichnis sollte existieren und Platz 
haben
syslog = 0

Restarte dann die Dienste.

Nun solltest du recht aussagekräftige Logs bekommen.
(Nicht vergessen, wieder zurückzusetzen)
Such dir in den Logs einen fehlerhaften und einen guten Logon heraus.
Du solltest also in den Logs erkennen, wer sich anmeldet und ob und wie es 
schiefgeht. Die Daten, die da ausgetauscht werden, sollten in den .tdb files 
findbar sein. Mit tdbdump kannst du da mal durchschauen.

Interessant wäre es, wenn ein User von Maschine X sich einloggen kann, von 
Maschine Y aber nicht. Da sollten die Unterschiede im Log recht deutlich 
herauskommen.

Unter  /var/lib/samba findest du die Dateien, in denen alles steht, was von 
Interesse sein könnte.
Du solltest das Paket tdb-tools installiert haben.
Debian:
# aptitude show tdb-tools
# aptitude -r install tdb-tools

Damit kannst du dann z.B. die SID's des Logons der User aus dem Winbind-Cache 
auslesen:

# tdbdump winbindd_idmap.tdb
...
{
key = "S-1-5-21-675436986-43124466-1478062314-1208\00"
data = "UID 10086\00"
}
...

und sie dann mit:

# wbinfo -s  S-1-5-21-675436986-43124466-1478062314-1208
DOMAIN/Xyz 1

gegenprüfen.

# tdbbackup -v /var/lib/samb/*.tdb #checkt alle Samba-tdbfiles in diesem 
Verzeichnis auf integrität.

Grüsse, Jürgen