Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Domänenjoin ohne UID != 0

2 views
Skip to first unread message

Peter Mairhofer

unread,
Aug 25, 2009, 4:29:18 PM8/25/09
to
Hi,

Wieso benï¿œtigt Samba fï¿œr den Join einer Domï¿œne einen User mit UID 0?
Sogar wenn der Maschinenaccount bereits im LDAP existiert?!

Ich verwende den User "admin" fï¿œrs Beitreten zur Domï¿œne und es ist
extrem lï¿œstig nur deswegen im LDAP immer die UID temporï¿œr auf 0 setzen
zu mï¿œssen und dann wieder zurï¿œck.

Gibt es eine Mï¿œglichkeit dies zu umgehen?

lg,
Peter

Jan Wenzel

unread,
Aug 26, 2009, 4:44:44 AM8/26/09
to
Peter Mairhofer schrieb:

Hallo,

das uid=0 Problem ist eigentlich gefixt, es reicht bei aktuellen
Samba-Versionen (ich weiss nicht, wie es bei 3.0 aussieht), wenn die
passenden Privilegien assigned sind.

net rpc rights list
und
net rpc rights list accounts

schaffen Klarheit :)

HTH
Jan

Peter Mairhofer

unread,
Aug 26, 2009, 6:18:30 AM8/26/09
to
Jan Wenzel schrieb:

> Peter Mairhofer schrieb:
>> Hi,
>>
>> Wieso benï¿œtigt Samba fï¿œr den Join einer Domï¿œne einen User mit UID 0?
>> Sogar wenn der Maschinenaccount bereits im LDAP existiert?!
>>
>> Ich verwende den User "admin" fï¿œrs Beitreten zur Domï¿œne und es ist
>> extrem lï¿œstig nur deswegen im LDAP immer die UID temporï¿œr auf 0 setzen
>> zu mï¿œssen und dann wieder zurï¿œck.
>>
>> Gibt es eine Mï¿œglichkeit dies zu umgehen?
>>
>> lg,
>> Peter
>
> Hallo,
>
> das uid=0 Problem ist eigentlich gefixt, es reicht bei aktuellen
> Samba-Versionen (ich weiss nicht, wie es bei 3.0 aussieht),

3.2.5 aus Debian Lenny :-)

> wenn die
> passenden Privilegien assigned sind.
>
> net rpc rights list
> und
> net rpc rights list accounts
>
> schaffen Klarheit :)

Aaah, vielen Dank fï¿œr den Hinweis! Das ist gut!

Nun bin ich aber sehr verwundert. Das ist wohl die Standardausgabe oder:

# net rpc rights list accounts -U admin
Enter admin's password:
BUILTIN\Print Operators
No privileges assigned

BUILTIN\Account Operators
No privileges assigned

BUILTIN\Backup Operators
No privileges assigned

BUILTIN\Server Operators
No privileges assigned

BUILTIN\Administrators
SeMachineAccountPrivilege
SeTakeOwnershipPrivilege
SeBackupPrivilege
SeRestorePrivilege
SeRemoteShutdownPrivilege
SePrintOperatorPrivilege
SeAddUsersPrivilege
SeDiskOperatorPrivilege

Everyone
No privileges assigned

Nun weiss ich, dass ich vor laaanger Zeit (wie ich das alles
eingerichtet hab) sogenannte "groupmaps" eingerichtet habe. Die dienen
AFAIR dazu, die Builtin-Gruppen zu UNIX Gruppen zu mappen und dadurch
Benutzer zu Gruppen hinzufï¿œgen zu kï¿œnnen.

Bei mir sieht das aber nun so aus:

# net groupmap list
Domain Admins (S-1-5-21-3909901412-745783496-1225843668-512) -> Domain
Admins
Domain Users (S-1-5-21-3909901412-745783496-1225843668-513) -> Domain Users
Domain Guests (S-1-5-21-3909901412-745783496-1225843668-514) -> Domain
Guests
Domain Computers (S-1-5-21-3909901412-745783496-1225843668-515) ->
Domain Computers
Administrators (S-1-5-32-544) -> Administrators
Account Operators (S-1-5-32-548) -> Account Operators
Print Operators (S-1-5-32-550) -> Print Operators
Backup Operators (S-1-5-32-551) -> Backup Operators
Replicators (S-1-5-32-552) -> Replicators

Sieht mir eigentlich so aus als ob meine ï¿œnderungen verschwunden sind
(ich kann mich leider nicht mehr genau erinnern, aber ich glaube ich ein
Mapping auf die Gruppe "admins" gemacht und die Ausgabe sieht jetzt sehr
nach Standard aus). Ich hab irgendwann mal nach LDAP migriert -
vielleicht gingen die Mappings dort verloren.

Ausserdem: Wieso gibt es auf einmal "Domain Admins" und
"Administrators"? Mï¿œsste nicht eigentlich die Gruppe "Domain Admins" das
Recht "SeMachineAccountPrivilege" haben? Denn hier wï¿œre der User admin -
wenn ich es richtig verstehe - Mitglied:

# id admin
uid=1013(admin) gid=1013(admin)
Gruppen=1013(admin),3(sys),34(backup),37(operator),200(admins),1019(daten),1022(donkey),101(lpadmin),512(Domain
Admins)

Wo jetzt die Gruppe "Domain Admins" herkommt weiss ich ï¿œbrigens auch nicht.

Wï¿œre es korrekt folgende Mappings zu setzen?

Domain Admins (S-1-5-21-3909901412-745783496-1225843668-512) -> admins
Domain Users (S-1-5-21-3909901412-745783496-1225843668-513) -> users
Domain Guests (S-1-5-21-3909901412-745783496-1225843668-514) -> nobody
Domain Computers (S-1-5-21-3909901412-745783496-1225843668-515) ->
Domain Computers
Administrators (S-1-5-32-544) -> admins
Account Operators (S-1-5-32-548) -> operator
Print Operators (S-1-5-32-550) -> lpadmin
Backup Operators (S-1-5-32-551) -> backup
Replicators (S-1-5-32-552) -> ?????????


Danke und lg,
Peter

Jan Wenzel

unread,
Aug 26, 2009, 7:46:00 AM8/26/09
to
Peter Mairhofer schrieb:

Die Mappings wurden vermutlich in einer lokalen Datei gespeichert und
deren Inhalt
ist vermutlich verloren gegangen (wie Du schon vermutest).

> Ausserdem: Wieso gibt es auf einmal "Domain Admins" und
> "Administrators"? Mï¿œsste nicht eigentlich die Gruppe "Domain Admins" das
> Recht "SeMachineAccountPrivilege" haben? Denn hier wï¿œre der User admin -
> wenn ich es richtig verstehe - Mitglied:

Die beiden Gruppen sind in Ihrer Bedeutung unterschiedlich, vergleiche
auch die SIDs. Administrators ist eine lokale Gruppe, Domain Admins eine
Domaenengruppe.

> # id admin
> uid=1013(admin) gid=1013(admin)
> Gruppen=1013(admin),3(sys),34(backup),37(operator),200(admins),1019(daten),1022(donkey),101(lpadmin),512(Domain
> Admins)
>
> Wo jetzt die Gruppe "Domain Admins" herkommt weiss ich ï¿œbrigens auch nicht.
>
> Wï¿œre es korrekt folgende Mappings zu setzen?
>
> Domain Admins (S-1-5-21-3909901412-745783496-1225843668-512) -> admins
> Domain Users (S-1-5-21-3909901412-745783496-1225843668-513) -> users
> Domain Guests (S-1-5-21-3909901412-745783496-1225843668-514) -> nobody
> Domain Computers (S-1-5-21-3909901412-745783496-1225843668-515) ->
> Domain Computers
> Administrators (S-1-5-32-544) -> admins
> Account Operators (S-1-5-32-548) -> operator
> Print Operators (S-1-5-32-550) -> lpadmin
> Backup Operators (S-1-5-32-551) -> backup
> Replicators (S-1-5-32-552) -> ?????????
>
>
> Danke und lg,
> Peter

Eigentlich werden die Mappings in Deinem Fall nicht mehr benoetigt, da
es ja bereits Mappings gibt :) Ich schlage Dir also vor, einfach der
Domain Admins Gruppe die entsprechenden Rechte zu erteilen. Dies kannst
Du entweder auf dem NT4-Weg erledigen, indem Du die Domain Admins zu der
lokalen Gruppe Administrators hinzufuegst, oder ueber den
Privilegien-Weg per 'net rpc rights grant'. Letztendlich bleibt es Dir
ueberlassen :)

Gruss
Jan

Peter Mairhofer

unread,
Aug 26, 2009, 8:10:06 AM8/26/09
to
Jan Wenzel schrieb:
> Peter Mairhofer schrieb:
>> [...]

>> Wï¿œre es korrekt folgende Mappings zu setzen?
>>
>> Domain Admins (S-1-5-21-3909901412-745783496-1225843668-512) -> admins
>> Domain Users (S-1-5-21-3909901412-745783496-1225843668-513) -> users
>> Domain Guests (S-1-5-21-3909901412-745783496-1225843668-514) -> nobody
>> Domain Computers (S-1-5-21-3909901412-745783496-1225843668-515) ->
>> Domain Computers
>> Administrators (S-1-5-32-544) -> admins
>> Account Operators (S-1-5-32-548) -> operator
>> Print Operators (S-1-5-32-550) -> lpadmin
>> Backup Operators (S-1-5-32-551) -> backup
>> Replicators (S-1-5-32-552) -> ?????????
>
> Eigentlich werden die Mappings in Deinem Fall nicht mehr benoetigt, da
> es ja bereits Mappings gibt :) Ich schlage Dir also vor, einfach der
> Domain Admins Gruppe die entsprechenden Rechte zu erteilen. Dies kannst
> Du entweder auf dem NT4-Weg erledigen, indem Du die Domain Admins zu der
> lokalen Gruppe Administrators hinzufuegst,

Das wï¿œrd ich gern tun, ja. Nur hakts auch hier:

# net rpc group MEMBERS 'Domain Admins' -U admin
Enter admin's password:
DOM01\admin
# net rpc group MEMBERS 'Administrators' -U admin
Enter admin's password:
Couldn't list alias members
# net rpc group ADDMEM 'Administrators' 'Domain Admins' -U admin
Enter admin's password:
Could not add Domain Admins to Administrators: NT_STATUS_NO_SUCH_ALIAS
#

Aber auch mit dem geht es nicht:

# net sam addmem 'Administrators' 'Domain Admins'
Adding local group member failed with NT_STATUS_NO_SUCH_ALIAS
#

Aber nur grundsï¿œtzlich zu den Mappings: Die o.g. sind alle eingebaut und
unabhï¿œngig von der Domï¿œne oder? Mï¿œssen die UNIX Gruppen fï¿œr die Mappings
tatsï¿œchlich existieren?

Denn darauf zielt eigentlich meine Frage auch ab: Wie handhabt man die
Mappings am besten? Irgendwie mï¿œchte ich keine UNIX Gruppen wie "Account
Operators" rumgurken haben, deswegen wollte ich diese UNIX Pendants
zuordnen (operator, backup, lpadmin, users, ...)

Gibts fï¿œr die Handhabung eine "Best practice"?

Achja, wieso liefert

# net sam list builtin -U admin
#

ein leeres Ergebnis, jedoch

# net sam list groups -U admin
Domain Admins
Domain Users
Domain Guests
Domain Computers
#

nicht alle Gruppen die mit "net groupmap list" erscheinen? Das Ergebnis
ist ï¿œbrigens die gleiche Liste wie mit "net group" und "net sam list
groups".

Der Rest liefert wirder leeres Ergebnis:

# net sam list localgroups -U admin
# net sam list builtin -U admin
#

Hab ich hier vielleicht bereits eine Inkosistenz? Oder gibt es beim
"net" Befehl bereits Redundanzen? Irgendwie blick' ich grad nicht ganz
durch...

LG,
Peter

Jan Wenzel

unread,
Aug 26, 2009, 9:55:59 AM8/26/09
to
Peter Mairhofer schrieb:

> Jan Wenzel schrieb:
>> Peter Mairhofer schrieb:
[...]

Lokale Gruppe <-> Domaenengruppe


> nicht alle Gruppen die mit "net groupmap list" erscheinen? Das Ergebnis
> ist ï¿œbrigens die gleiche Liste wie mit "net group" und "net sam list
> groups".
>
> Der Rest liefert wirder leeres Ergebnis:
>
> # net sam list localgroups -U admin
> # net sam list builtin -U admin
> #
>
> Hab ich hier vielleicht bereits eine Inkosistenz? Oder gibt es beim
> "net" Befehl bereits Redundanzen? Irgendwie blick' ich grad nicht ganz
> durch...
>
> LG,
> Peter

Vielleicht ist da wirklich was kaputt, hier gehts jedenfalls:


# net sam list builtin

Administrators
Users
Guests

Was ist Dein Konfigurationswert fuer 'winbind nested groups'?
Hast Du denn Mal "net rpc rights grant 'Domain Admins'
SeMachineAccountPrivilege" probiert?

Gruss
Jan

Peter Mairhofer

unread,
Aug 27, 2009, 9:13:29 AM8/27/09
to
Jan Wenzel schrieb:
> [...]
>
> Lokale Gruppe <-> Domaenengruppe

Aha, das bedeutet die Gruppen "Domain *" sind Domï¿œnengruppen und die
anderen lokale? Also die lokalen des Servers?

Wieso kann dann standardmￜￜig nur ein Benutzer der Mitglied der
*lokalen* Administratorgruppe des Servers ist andere Maschinen zur
Domï¿œne hinzufï¿œgen? Die lokale admin Gruppe wï¿œre in der Domï¿œne dann ja
gar nicht bekannt oder? Irgendwie ist das unlogisch, die Rechte mï¿œsste
IMHO die Gruppe "Domain Admins" haben...

Das "net"-Kommando hat x verschiedene und unï¿œbersichtliche
Befehlsgruppen fï¿œr User/Gruppenmanagement. Was ist nun fï¿œr was?

Ich dachte:
* net user/net group: Lokal
* net sam *: Lokal
* net rpc *: Domï¿œnenuser

Aber irgendwie scheint das nicht zu sein. Alle liefern irgendwie die
Domï¿œnendaten.

> [...]


> Vielleicht ist da wirklich was kaputt, hier gehts jedenfalls:
> # net sam list builtin
> Administrators
> Users
> Guests

Oje :-(

> Was ist Dein Konfigurationswert fuer 'winbind nested groups'?

Ich verwende kein Winbind. Das ist doch nur wenn ein UNIX Client
Mitglied einer Domï¿œne sein soll oder?

> Hast Du denn Mal "net rpc rights grant 'Domain Admins'
> SeMachineAccountPrivilege" probiert?

# net rpc rights grant 'Domain Admins' SetMachineAccountPrivilege -U admin
Enter admin's password:
Failed to grant privileges for Domain Admins (NT_STATUS_NO_SUCH_PRIVILEGE)
#

Nein. Aber ich komme grad drauf: Bei mir gibt es "root" in Samba nicht.
Dafï¿œr hï¿œtte ich eigentlich "admin" gedacht.

Funktionieren die ganzen Befehle vielleicht nur wenn ich "net" als UID=0
ausfï¿œhre UND der Benutzer in Samba existiert?

LG,
Peter

Jan Wenzel

unread,
Aug 27, 2009, 10:21:26 AM8/27/09
to
Peter Mairhofer schrieb:

> Jan Wenzel schrieb:
>> [...]
>>
>> Lokale Gruppe <-> Domaenengruppe
>
> Aha, das bedeutet die Gruppen "Domain *" sind Domï¿œnengruppen und die
> anderen lokale? Also die lokalen des Servers?
>
> Wieso kann dann standardmￜￜig nur ein Benutzer der Mitglied der
> *lokalen* Administratorgruppe des Servers ist andere Maschinen zur
> Domï¿œne hinzufï¿œgen? Die lokale admin Gruppe wï¿œre in der Domï¿œne dann ja
> gar nicht bekannt oder? Irgendwie ist das unlogisch, die Rechte mï¿œsste
> IMHO die Gruppe "Domain Admins" haben...
>
> Das "net"-Kommando hat x verschiedene und unï¿œbersichtliche
> Befehlsgruppen fï¿œr User/Gruppenmanagement. Was ist nun fï¿œr was?
>
> Ich dachte:
> * net user/net group: Lokal
> * net sam *: Lokal
> * net rpc *: Domï¿œnenuser
>
> Aber irgendwie scheint das nicht zu sein. Alle liefern irgendwie die
> Domï¿œnendaten.
Das sind ja auch nur Varianten, die die Form des Zugriffs bestimmen. Bei
'net rpc'
werden die Funktionen als 'Remote Procedure Call' (=RPC) ausgefuehrt,
das geht
dann auch auf entfernten Hosts.

>> [...]
>> Vielleicht ist da wirklich was kaputt, hier gehts jedenfalls:
>> # net sam list builtin
>> Administrators
>> Users
>> Guests
>
> Oje :-(
>
>> Was ist Dein Konfigurationswert fuer 'winbind nested groups'?
>
> Ich verwende kein Winbind. Das ist doch nur wenn ein UNIX Client
> Mitglied einer Domï¿œne sein soll oder?

Das galt fuer Samba 3.0 - ab 3.2 laueft der eigentlich mit, solange man
keine abgefahrenen Setups baut.

>> Hast Du denn Mal "net rpc rights grant 'Domain Admins'
>> SeMachineAccountPrivilege" probiert?
>
> # net rpc rights grant 'Domain Admins' SetMachineAccountPrivilege -U admin
> Enter admin's password:
> Failed to grant privileges for Domain Admins (NT_STATUS_NO_SUCH_PRIVILEGE)
> #

Das gute alte Copy&Paste, es muss natuerlich heissen
net rpc rights grant 'Domain Admins' SeMachineAccountPrivilege -U admin
(kein 'Set' sondern 'Se', wie SEcurity).


> Nein. Aber ich komme grad drauf: Bei mir gibt es "root" in Samba nicht.
> Dafï¿œr hï¿œtte ich eigentlich "admin" gedacht.
>
> Funktionieren die ganzen Befehle vielleicht nur wenn ich "net" als UID=0
> ausfï¿œhre UND der Benutzer in Samba existiert?

Nein

> LG,
> Peter


Gruss
Jan

Peter Mairhofer

unread,
Aug 28, 2009, 8:49:46 AM8/28/09
to
Jan Wenzel schrieb:

> Peter Mairhofer schrieb:
>> Jan Wenzel schrieb:
>> [...]
> Das sind ja auch nur Varianten, die die Form des Zugriffs bestimmen. Bei
> 'net rpc'
> werden die Funktionen als 'Remote Procedure Call' (=RPC) ausgefuehrt,
> das geht
> dann auch auf entfernten Hosts.

Aaah, danke!

>>> [...]


>>> Was ist Dein Konfigurationswert fuer 'winbind nested groups'?
>> Ich verwende kein Winbind. Das ist doch nur wenn ein UNIX Client
>> Mitglied einer Domï¿œne sein soll oder?
> Das galt fuer Samba 3.0 - ab 3.2 laueft der eigentlich mit, solange man
> keine abgefahrenen Setups baut.

Also in Debian ist das ein extra Paket und das hab ich nicht
installiert. Stand auch nirgends dass man das soll. Trotzdem lï¿œuft das
Ding gut als PDC

>>> Hast Du denn Mal "net rpc rights grant 'Domain Admins'
>>> SeMachineAccountPrivilege" probiert?
>> # net rpc rights grant 'Domain Admins' SetMachineAccountPrivilege -U admin
>> Enter admin's password:
>> Failed to grant privileges for Domain Admins (NT_STATUS_NO_SUCH_PRIVILEGE)
>> #
> Das gute alte Copy&Paste, es muss natuerlich heissen
> net rpc rights grant 'Domain Admins' SeMachineAccountPrivilege -U admin
> (kein 'Set' sondern 'Se', wie SEcurity).

Aaah, jetzt geht es!

Hab jetzt einfach BUILTIN\Administrators alle Rechte genommen (ich glaub
dass ist standard) und der Gruppe "Domain Admins" alle Rechte gegeben.

Jetzt funktioniert der Join auch ohne UID 0.

LG
Peter

0 new messages