Archiv verlassen und diese Seite im Standarddesign anzeigen : LDAP Gruppenverwaltung
Ich weiß...leidiges Thema...aber möchte ne Gruppenverwaltung mit LDAP und Samba für W2k Client-User erstellen. Meine LDIF Datei sieht wie folgt aus...und PAM ist auch schon Konfiguriert....aber wie geht es denn nun weiter....? Ist ja nix mit Berechtigungen zusammenklicken wie bei em 2000 Server...und außerdem brauch ich immer noch root um mich vom Client in der Domäne anzumelden...mit dem ldapadmin geht es einfach nicht, obwohl der in der smb.conf und slapd.conf angegeben ist..:
dn: cn=ldapadmin,ou=people,dc=samba,dc=de
objectClass : personhomeDirectory: /home/ldapuser1
objectClass: posixAccount
cn: ldapadmin
sn: Nachname
uid: ldapadmin
uidNumber: 1002
gidNumber: 100
loginShell: /bin/bash
homeDirectory: /home/ldapadmin
dn: cn=administratoren,ou=groups,dc=samba,dc=de
objectClass: posixGroup
cn: administratoren
gidNumber : 1000
memberUid : ldapadmin
memberUid : root
Freu mich über Antworten
Gruß
Peter
hi
sieht ein bisschen wirr bei dir aus (oder liegt es daran, dass ich übermüdet bin? :D )
so sehen meine templates für user (samba/posix) aus
# $USERNAME, $OU, $DOMAIN
dn: uid=$USERNAME,ou=$OU,$BASEDN
objectclass: posixAccount
objectclass: person
objectclass: sambaSamAccount
cn: $USERNAME
uid: $USERNAME
sn: $USERNAME
displayName: $USERNAME
uidNumber: $UserID
gidNumber: $GroupID
sambaSID: $DOMAINSID-$RID
sambaPrimaryGroupSID: $DOMAINSID-513
homeDirectory: $HOME_DIR
loginShell: /bin/false
userPassword:: none
sambaAcctFlags: [U ]
sambaHomeDrive: U:
sambaHomePath: \\\\$PDC_NAME\\$USERNAME
sambaLogonScript: $USERNAME.bat
dieses wird in den lpap tree eingefügt
zuvor muss aber noch ein gültiger root account drin sein, die domäne, ID Mappings, POSIX gruppen, und und und....
such mal hier im forum nach samba und ldap, ein wikki findest du dabei auch
mit vorlagen zur ldap struktur
nur der user root hat übrigens die vollen rechte in der domäne (maschinen remote hinzufügen, user adden via GUI, ... ) - es sei denn du mapst andere user auf root (usermap) - selbst wenn du user der admin-gruppe hinzufügst ("memberUid:"), haben die nicht die vollen berechtigungen
greez
greez
Nö...glaub muss nicht unbedingt so sein, gibt da glaube viele Alternativen. Hab leider bis jetzt noch nix von einer "Üblichen Vorgehensweise" zu den verschiedenen Attributen gelesen...vielleicht hast Du ja ne Quelle.
Verschiedene Attribute hab ich z.B. nicht und auch diverse Unstimmigkeiten. Kommentier die Dinger einfach...wenn's falsch ist kannst Du ja vielleicht en kurzen hinweis geben....?
objectclass: posixAccount //Linux Benutzer
objectclass: person //Standart Person
objectclass: sambaSamAccount //Samba Benutzer
sambaSID: $DOMAINSID-$RID //ID vom Samba PDC (erstellt der selber)
sambaPrimaryGroupSID: $DOMAINSID-513 //Weiß nicht so
sambaHomePath: \\\\$PDC_NAME\\$USERNAME //Userverzeichniss (smb.conf)
sambaLogonScript: $USERNAME.bat //LoginScript (smb.conf)
Gruß
Peter
ich hab auch nirgends geschrieben, dass es so sein muss, wie ich gepostet habe ;)
natürlich gibt es schon durch die verschiedenen objectklassen (top, auxiliary, ... ) verschiedene ergebnisse
du kannst natürlich einige pfade (homepath, ... ) in der smb.conf statisch für alle festlegen, dies wollte ich jedoch nicht und habe es in das verzeichnis ausgelagert
da ich nicht mit den smbldaptools von idealx arbeite, habe ich mir selbst scripte zur verwaltung gestrickt
die resultieren dann in solchen "VARIABEL-WIRRWARR"
sambaPrimaryGroupSID: $DOMAINSID-513 //Weiß nicht so
weist den user/maschine einer primärgruppe (hier benutzer) zu - sind wellknown sids und $DOMAINSID entspricht logischerweise der eindeutigen SID in der domäne (wie im dn eintrag für die domäne hinterlegt)
der rest ist richtig kommentiert
hast du das wikki net gefunden?
war glaub ich von "mrich" oder "mr.ich" (mod hier)
auch mamue hat erfahrung in ldap+samba
alle anderen von mir angegebenen attribute sind "required attributes" der jeweiligen objectclasses
greez
Original geschrieben von pnuernbe
1.: objectclass: posixAccount //Linux Benutzer
2.: objectclass: person //Standart Person
3.: objectclass: sambaSamAccount //Samba Benutzer
4.: sambaSID: $DOMAINSID-$RID //ID vom Samba PDC (erstellt der selber)
5.: sambaPrimaryGroupSID: $DOMAINSID-513 //Weiß nicht so
6.: sambaHomePath: \\\\$PDC_NAME\\$USERNAME //Userverzeichniss (smb.conf)
7.: sambaLogonScript: $USERNAME.bat //LoginScript (smb.conf)
Das, was emba geschrieben hat, so ok. aus.
Die Zeilen 1. und 3. sind klar. Du brauchst 2., weil 1. und 3. keine Strukturellen Objektklassen sind. Jeder Eintrag braucht genau eine. Ich habe "top" genommen, andere nehmen "person" oder inetOrgPerson.
4. Die Domain-SID wird von Samba beim ersten Start selber ermittelt oder stammt von Deiner älteren Samba-version. Die RID muss für jeden Eintrag unbedingt verschieden sein! Normalerweise wird sie aus der uidNumber berrechnet, etwa (uidNumber+1000)*2, sieh mal in die samba Doku (algorithmic rid). Du kannst sie seit samba3 auch frei wählen, aber sie sollte wirklich eindeutig sein, bis auf wenige Ausnahmen. Wenn mehrere Personen Domain-administratoren sein sollen, kannt Du denen auch die spezielle RID 512 geben.
Ich würde mir gut überlegen, ob ich wirklich 6. in die Einträe schreiben möchte, oder das nicht lieber in der smb.conf lasse. Bei dieser Variante wird der Aufbau eines BDC schwierig. Wenn 6. auf den PDC verweist und dieser ausfällt, hilft die der BDC nicht mehr. Steht das hingegen in der smb.conf, kann das auf beiden servern von einander abweichen. Vielleicht kann man aber auch Variablen in 6. einsetzen, also:
6.: sambaHomePath: \\\\%L\\$USERNAME
Danach musst Du noch die Gruppen einrichten und dort das sambaGroupMapping eintragen. Wenn Du dann noch ein ACL fähiges Dateisystem einsetzt, das samba unterstützt (XFS), dann klappt das auch mit der Benutzerverwaltung unter w2k/NT4. Dann kann man z.B. auf den NT$ Kisten die eigen sambaGruppe fooBah zu Hauptbenutzern machen.
Viel Spass,
mamue
@mamue
jo, könnte probs mit PDC/BDC bei ausfall des PDC geben, aber ich habe neuerdings die profile/files net auf dem PDC sondern auf einem extra fileserver ausgelagert, von daher sollte dies dann auch gehen - so, wie oben abgebildet, kann es aber wahrlich zu problemen kommen, wenn der PDC ausfällt und man mit backup lösungen wie BDC arbeitet
afaik akzeptiert/versteht der client, wenn er sein profil in einem string wie \\\\%L\\$USERNAME bekommt, nicht diese schreibweise...er weiß ja nicht, was er substituieren soll - dies klappt so nur in der smb.conf
was hat das ACL fähige FS mit der benutzerverwaltung im direkten sinne zu tun?
weitere ACL-fähige FS sind reiserfs, ext2/3
greez
was hat das ACL fähige FS mit der benutzerverwaltung im direkten sinne zu tun?
...ein ACL fähiges System ist der Grundtein der Benutzerwerwatung mit Dateirechten...und für jeden W2K Server und Novell Netzwerker selbstverständlich.
Dieser Artikel gibt einen kleinen Überblick :
http://www.pl-berichte.de/t_system/print/ext2_acl.html
Des weiteren möchte der Anhänger kommerzieller Software auch Datenträgerkontigente einrichten (auch unversichtbar) heiß bei Linux Quotas.
Ein Workshop :
http://www.lug-hbs.de/linux_workshops/quotas.html
Nur wenn diese Voraussetzungen geschaffen sind...könte man von einem echten Samba -PDC sprechen, da ein PDC all die Funktionen beherbergt.
Gruß
pnuernbe
Würd mich freuen wnn Du mir sagen könntest wie das
Groupmapping funzt...
pnuernbe
@pn
mir schon klar, dass ich mit den ACLs granulierte berechtigungen setzen kann, was ich in meiner domäne für die zugriffe auf shares ja auch mache....
nur kann das ACL FS auch ohne gruppenverwaltung via ldap-backend exisitieren und umgekehrt - deshalb habe ich nach der direkten beziehung (abhängigkeit beider gefragt) - okay, seis drum
zum usermapping
net groupmap list
zeigt dir deine aktuellen mappings von NT-User auf Unix-User
ein eintrag im ldap backend, um die NT-Gruppe "Benutzer" auf die Unix Gruppe "Benutzer" abzubilden, muss folglich so aussehen, damit, wenn samba sich die user/gruppen aus ldapsam holt, die mappings klappen
/bin/cat <<EOF>/tmp/ldap/groupadd.ldif
# $GROUPNAME, $OUGROUP, $DOMAIN
dn: uid=$GROUPNAME,ou=$OUGROUP,$BASEDN
objectClass: posixGroup
objectClass: uidObject
objectClass: sambaGroupMapping
cn: $GROUPNAME
uid: $GROUPNAME
gidNumber: $GroupID
sambaSID: $DOMAINSID-$GRID
sambaGroupType: 2
displayName: $GROUPNAME
EOF
/bin/cat <<EOF>/tmp/ldap/idmapadd.ldif
# $GroupID, $OUIDMAP, $DOMAIN
dn: gidNumber=$GroupID,ou=$OUIDMAP,$BASEDN
objectClass: person
objectClass: sambaIdmapEntry
cn: $GROUPNAME
sn: $GROUPNAME
gidNumber: $GroupID
sambaSID: $DOMAINSID-$GRID
EOF
erklärung der VARS
GROUPNAME=Benutzer
OUGROUP=Organisational Unit, unterhalb der die gruppen befinden (groups, ... )
OUIDMAP=Organisational Unit, unterhalb der die IDMAPings gespeichert werden
BASEDN=anzuhängende DN (dc=your,dc=domain,dc=de)
DOMAIN=Samba Domain Name (testdomain, ... )
GroupID=GID der neuen Gruppe "Benutzer" (nächst freie wählen oder raussuchen lassen via script)
DOMAINSID=SID der Domäne
GRID=(2 x GroupID von POSIXGROUP "Benutzer") + 1001
greez
Original geschrieben von emba
@mamue
1.: afaik akzeptiert/versteht der client, wenn er sein profil in einem string wie \\\\%L\\$USERNAME bekommt, nicht diese schreibweise...er weiß ja nicht, was er substituieren soll - dies klappt so nur in der smb.conf
2.: was hat das ACL fähige FS mit der benutzerverwaltung im direkten sinne zu tun?
3.: weitere ACL-fähige FS sind reiserfs, ext2/3
greez
1.: So etwas hatte ich befürchtet. Also brauche ich das nicht mehr auszuprobieren. Ich hatte gehofft, dass samba das vorher ersetzt.
2.: Nun ja, wozu wollte ich Benutzer/Gruppen verwalten? Zu allererst doch wohl, um bestimmten Gruppen Rechte, etwa im Dateisystem zuzuordnen. Oder um Gruppen einen bestimmten Status (Hauptbenutzer) zu erteilen. Ersteres klappt nur mit einem von samba unterstütztem ACL-fähigen FS. Einen _direkten_ Bezug gabe es da aber nicht, ich bin wohl abgeschwiffen ;-)
3.: ext3 und reiserFS sind ebenfalls ACL fähig, aber ob das auch mit samba klappt, weiss ich nicht. Ich glaube, getestet wurde das nur mit XFS.
mamue
So Ihr Freaks...in kleinen Schritten..aber geht doch weiter.
Das mit den zwei ldif Dateien probier ich auch noch aus...scheint mir aber immer nur für eine Grupe zu gelten...oder?
Hab's in der zwischenzeit mal mit den scripts von idealex probiert und folgendes Ergebnis :
linux:/usr/local/sbin # ./smbldap-groupadd.pl -a -r 512 "Domain Admins"
linux:/usr/local/sbin # net groupmap list
Domain Admins (S-1-5-21-515308762-1151918503-1676858975-512) -> Domain Admins
linux:/usr/local/sbin #
Jetzt müsste doch noch ne Unix Gruppe namen "Domain Admins" anlegen um zwei Gruppen 1x Windows...1xUnix mit gleichen berechtigungen zu haben...oder ?
pnuernbe
@mamue
ich habs erfolgreich (ACL) mit reiser und ext3 getestet
@pn
wenn das mapping so erscheint, muss schon eine unix gruppe existieren bzw. von den tools angelegt worden sein
schau mal ins backend, ob da eine gruppe (UNIX) "domain admins" existiert
das mapping an sich ist nur virtueller natur, sprich: in wirklichkeit existiert nur die unix-gruppe und bei zugriffen via smb auf die NT gruppen werden diese automatisch auf die unix-group gemapt - dieses mapping läuft dann mittels IDMAP im backend ab - nur mal zum allgemeinen verständnis
greez
Hallo,
ja ist eine Gruppe namens "Domain Admins" in der LDAP Datenbank (backend) unter ou=groups angelegt worden. Sieht so aus:
dn: cn=Domain Admins,ou=groups,dc=samba,dc=de
objectClass: posixGroup
objectClass: sambaGroupMapping
cn: Domain Admins
gidNumber: 1001
sambaSID: S-1-5-21-515308762-1151918503-1676858975-512
sambaGroupType: 2
...das mapping an sich ist nur virtueller natur...
O.K. hab ich glaube verstanden...die NT Gruppe wird gemappt...also spielt der Name der Gruppe eigentlich keine Rolle, sondern nur die RID (512).
Wofür brauch ich jetzt noch das IDMAP ?
...kann auf jeden Fall die Domain Admins im NT Usermanager sehen, aber alerdings nicht bearbeiten...müsste man noch rausfinden wie man die Benutzer in die Gruppe bekommt...
pnuernbe
> müsste man noch rausfinden wie man die Benutzer in die Gruppe bekommt
Um Benutzer in dei Gruppe zu bekommen:
Die Benutzer bekommen die passende Unix GID (bei Dir z.B 1001) UND natürlich die passende RID (512) und passt schon ;)
Manx
das IDMAP brauchte ich immer, um dann samba zu sagen, dass die Unix Gruppe (hier Domain Admins) der NT Gruppe Domain Admins entspricht - bei dir scheint das komischerweise ohne zu gehen, ohne dass ich hier aber sagen kann, ob das so die saubere lösung ist
was hast du in der smb.conf als ldap suffix für IDMAP eingetragen? [1]
um einen benutzer in mehrere NT gruppen (und somit auch unix gruppen) zu bekommen, hilft dir das attribut memberUid in der entsprechenden gruppe weiter
greez
[1]
aus http://de.samba.org/samba/docs/man/smb.conf.5.html
ldap idmap suffix (G) =
idmap backend (G) =
Original geschrieben von pnuernbe
Hallo,
Wofür brauch ich jetzt noch das IDMAP ?
müsste man noch rausfinden wie man die Benutzer in die Gruppe bekommt...
Ich habe zwar idmap eingerichtet, brauche es aber scheinbar nicht. Schliesslich mache ich ja das mapping manuell, indem ich in die Gruppen eintrage, welche RID die hat und so fort.
Du bekommst die Benutzer nicht von Windows aus in die Gruppe, sondern nur mit den üblichen ldap-methoden. Etwa mittels ldapmodify mehrere memberUID der posixGroup hinzufügen, sofern die betreffende Gruppe nicht ohnehin die primaryGroup des users ist.
mamue
Hi mamue!
Frage (auch an emba ;) )
Habt Ihr das idmap im ldap mit "idmap backend = ldap:ldap://usw:389" bzw. "idmap suffix = irgendwo_im_ldaptree" oder lokal. Ich hatte es in meiner Testumgebung vorerst lokal (auf idmap backend vergessen) und hab's jetzt auf ldap umgelegt.
"net groupmap list" arbeitet korrekt, nur gibt's unter "ou = idmap usw" keine weiteren (sichtbaren) Einträge. Ist das normal so?
Grüße
Manx
ich habe es gleich mit den beiden von dir angegebenen parametern im ldap gemacht (idmap)
somit habe ich auch sauber, wie auch von den samba entwicklern empfohlen, die mappings zusätzlich zu den groupeinträgen in die idmap ou gelegt (weil ja auch so in der smb.conf angegeben)
ich weißt nicht, ob dies einfach nur effizienter ist oder bei späteren weiteren gruppenmappings vor fehlern schützen kann
dass deine mappings noch funzen kann auch daran liegen, weil die idmaps in idmap.tdb gecached werden
greez
emba
...was hast du in der smb.conf als ldap suffix für IDMAP eingetragen? [1]
Noch gar keinen, weiß ja nicht ob ich es wirklich brauche und was es genau macht oder ob nach dem mapping mit den smb-ldaptools alles so richtig ist ?
mamue
Ich habe zwar idmap eingerichtet, brauche es aber scheinbar nicht. Schliesslich mache ich ja das mapping manuell, indem ich in die Gruppen eintrage, welche RID die hat und so fort....
..Ja die RID spiegelt die Benutzerrechte in der Windows Domäne, bekommen jetzt automatisch die Unix Gruppen, welche ich der Gruppe Domadmins (512) hinzufüge die gleichen rechte ?
Gibt es keine Möglichkeit die Samba Benutzerverwaltung mit den mmc Tools zu gestalten. Mein habe so etwas in der Samba-HOWTO-Collection geslesen. Sehe die Gruppen auch im NT Benutzermanager, kann sie aber nicht verwalten...
pnuernbe
Ich habe eine ou=idmap, aber da steht nichts. Gecached ist mit Sicherheit auch nichts, es ist schlicht so, dass Du das nicht brauchst, wenn Du einen reinen Samba PDC fährst und sicherstellen kannst, dass die uidNUmber und sambaSIDNumber auf allen server gleich ist. Da ich ldap repliziere, kann ich das.
Die special-RID regeln zum Teil die Benutzerrechte. IIRC genügt es aber nicht, die user in die local-group powerUsers einzutragen und sie sind es dann auch auf den Workstations - das muss man noch auf den einzelnen Workstations machen.
Das mmc-snap-in zu r Gruppenverwaltung funktioniert noch nicht, da bin ich mir sicher. Kann ja noch werden, wer weiß
mamue
@mamue
was hat uidNumber mit IDMAP zu tun?
die sambaSID muss ja auch gleich sein, da dies die domänenzugehörigkeit wiederspiegelt - oder meinst SID-RID ?
greez
Hi!
Also bei mir bleibt "ou = idmap usw." auch leer. Obwohl mir keine verdächtige *.tdb untergekommen ist.
Frage an emba:
Bekommst Du durch ein neues Groupmapping unterhalb von "ou = idmap" automatisch neue SambaIdmapEntrys? Wie schauen die aus?
Ich werd mal händisch einen anlegen!
Grüße
Manx
Original geschrieben von emba
@mamue
was hat uidNumber mit IDMAP zu tun?
die sambaSID muss ja auch gleich sein, da dies die domänenzugehörigkeit wiederspiegelt - oder meinst SID-RID ?
greez
wenig. Die SID beinhaltet aber auch die RID, wenn ich mich nicht irre, bzw die RID ist Bestandteil der SID. Schliesslich hat jeder user eine SID, nicht nur eine RID. Da sich die RID bei mir rechnerisch aus der uidNumber ergibt, weil es sonst wohl unüberschaubar würde, habe ich die uidNumber mit einbezogen.
mamue
Nochmal wegen der Abkürzungen...
verbessert mich einfach wenn ich falsch liege :
S-1-5-21-222222222-334234234243-2342342342-512
SID: (Security Identifier) Identifiziert die Domäne
RID: (Relative Identifier)Ist ganz rechts (512 DomAdmins) und Identifiziert die Benutzer unter Windows.
UID: Benutzer ID unter Linux
GID: Gruppen ID unter Linux
Beim UserMappen wird eine Gruppe angelegt, welche an einer RID zu erkennen ist. Meldet sich ein Benutzer der Gruppe an Samba an, bekommt er die Windows Rechte der RID Gruppe.Allersings weiß ich nicht wie er Unix Berechtigungen bekommt...muss das beim Mappen auch berücksichtigt werden, oder kann man die Gruppen einfach verschachteln ?
...und so sieht mein Mapping aus:
dn: cn=Domain Admins,ou=groups,dc=samba,dc=de
sambaSID: S-1-5-21-515308762-1151918503-1676858975-512
gidNumber: 1001 //Verschachtelung ?
memberUid: ldapuser1 //Mitglieder
sambaGroupType: 2 //Typ 2?
objectClass: posixGroup
objectClass: sambaGroupMapping
cn: Domain Admins
Zur Benutzerverwaltung:
The Windows 200x/XP MMC (Computer Management) Console can not be used to manage a Samba-3 server. For this you can use only the MS Windows NT4 Domain Server manager and the MS Windows NT4 Domain User Manager. Both are part of the SVRTOOLS.
EXE package mentioned later.
Hab den NT Benutzermanager unter 2000 laufen...sehe die Objekte, kann die Gruppen aber nicht verwalten...wirklich nicht möglich ?
pnuernbe
Hi!
Das mit ou=idmap verwirrt mich :(
So wie pnuernbe das in seinem ldif andeutet, kann ich das groupmapping gleich direkt in den posixGroup Eintrag mit hineinnehmen: z.B
dn: cn=domadmins,ou=Gruppen,dc=manx,dc=...
objectClass: top
objectClass: posixGroup
objectClass: sambaGroupMapping ### <= hier!
gidNumber: 10000
cn: domadmins
sambaSID: S-1-5-21-819553785-1162526613-2116679363-512
sambaGroupType: 2
displayName: Administratoren
==>
p166:/etc/ldap# net groupmap list
Administratoren (S-1-5-21-819553785-1162526613-2116679363-512) -> domadmins
Er möchte bei mir:
bei "ldapadd" unter displayName ein "single value" ("Domänen Administratoren" geht nicht) und Umlaute mag er auch keine.
Im Ldapbrowser "gq" kann ich das dann sehr wohl ändern.
Er löscht mir auch den gesamten Gruppen Eintrag bei "net groupmap delete usw"
@emba
Kannst Du so einen idmap-Entry als ldif posten, denn mit der Objectclass sambaIdmapEntry fang ich momentan nix an.
am weitertesten
Manx
PS: ich sollte wohl von Samba 3.0.0 weg ;)
erklärung oben von pnuernbe ist okay
Beim UserMappen wird eine Gruppe angelegt,
die gruppe (unix) muss vorher schon existieren, das maping ist rein virtueller natur
Allersings weiß ich nicht wie er Unix Berechtigungen bekommt...muss das beim Mappen auch berücksichtigt werden, oder kann man die Gruppen einfach verschachteln ?
UNIX berechtigungen bekommt er ja durch das mapping ;)
die NT Gruppe wird auf die UNIX Gruppe abgebildet....sprich: die DomAdmins (unter NT) haben die rechte der UNIX Gruppe 1001 (ID) im system bei deinem beispiel oben...
nochmal: das mapping (abbilden) ist virtueller natur und es werden keine NT Gruppen bei Samba/Unix angelegt
ich nutze erfolgreich als GUI zur verwaltung den usrmgr.exe aus dem NT ResKit - entsprechende anpassungen in der smb.conf bei den add/delete-scripten vorausgesetzt
Das mit ou=idmap verwirrt mich
diese einträge wurden bei mir automatisch angelegt, als ich einen NT PDC mit net rpc vampire abgezogen habe...wie gesagt: es geht auch ohne...nur sollte man der sauberkeit halber die IDMAPs zusätzlich in einen weiteren verzeichniszweig (ou=idmap) eintragen und dies in der smb.conf unter ldap idmap suffix vermerken
o wie pnuernbe das in seinem ldif andeutet, kann ich das groupmapping gleich direkt in den posixGroup Eintrag mit hineinnehmen
ja, evtl. haben die entwickler ja noch einiges seit "testing" geändert und dies ist nun auch möglich, vllt. auch nur, wenn ldap idmap suffix= nicht gesetzt ist (nicht getestet) ?!?
Kannst Du so einen idmap-Entry als ldif posten
# $GroupID, $OUIDMAP, $DOMAIN
dn: gidNumber=$GroupID,ou=$OUIDMAP,$BASEDN
objectClass: person
objectClass: sambaIdmapEntry
cn: $GROUPNAME
sn: $GROUPNAME
gidNumber: $GroupID
sambaSID: $DOMAINSID-$GRID
greez
O.K. emba...mit der virtuellen Natur der Gruppen ist hoffentlich schon klar.
Also, ist glaube bei mir doch was schief gelaufen..weil ich einfach nicht verstehe warum bei meinem net groupmap list vorne und hinten die Domain Admins stehen und nicht links die NT Gruppe und rechts die Unix Gruppe wie in der Samba howto.
Bei mir:
linux:/usr/local/samba/bin # ./net groupmap list
Domain Admins (S-1-5-21-515308762-1151918503-1676858975-512) -> Domain Admins
linux:/usr/local/samba/bin #
Samba howto:
Domain Admins (S-1-5-21-2547222302-1596225915-2414751004-512) -> domadmin
Den usrmgr.exe verwende ich auch, bekomme aber immer ein "Zugriff verweigert" wenn ich versuche auf die angezeigte Gruppe aus meinem net groupmap list (Domain Admins) zuzugreifen.
pnuernbe
weil ich einfach nicht verstehe warum bei meinem net groupmap list vorne und hinten die Domain Admins stehen
die frage kannst dir selbst beantworten, wenn du dich fragst, welchen namen die unixgruppe mit der GID 1001 hat ;)
ergo: nenne die unixgroup iim ldap mit der GID 1001 "Domain Admins" (sollte funzen)
greez
@pnuernbe
> Also, ist glaube bei mir doch was schief gelaufen..weil ich einfach nicht verstehe warum bei meinem net groupmap list vorne und hinten die Domain Admins stehen und nicht links die NT Gruppe und rechts die Unix Gruppe wie in der Samba howto.
Deine posixGroup für die DomainAdmins auf Linuxseite sollte IHMO auch ein single value sein, nämlich z.B domadmin. Es sind mir auf Linuxseite keine Gruppen bekannt, die aus zwei Teilen bestehen. Es ist auch ein Kommando wie ...
"chown Administrator."Domain Admins" irgendwas.txt
... komisch, wenn nicht sogar unmöglich.
Deshalb bekommt Deine posixGroup den DN: cn=domadmin,ou=groups,dc=samba,dc=de , über das GroupMapping machst Du dann für Windows z.B die "Domain Admins" draus.
@emba
Jetzt wird mir auch langsam klar woher bei Dir die idmapEntries kommen (vom NT4).
Denn ganz logisch finde ich die Einträge nicht.
sambaIdmapEntry ist eine Auxiliary Objectclass (ein Hilfsklasse) , die eine structural Objectclass voraussetzt (bei dir person).
Obwohl person damit nix zu tun hat, es ist ja ein Gruppe.
Interessant wird's erst, da ja auch ein uidNumber darin erlaubt wäre.
Das idmap-Backend habe ich immer im Zusammenhang mit winbindd gelesen.
Bei einem Samba Fileserver in einem Netz mit Windows PDC könnte ich mir vorstellen, dass der Samba Server für Linux dem Benutzer ABC (vom Windows Server), der eigentlich nur als SID-RID existiert eine virtuelle UID/GID für die Linux-Dateirechte anlegen muss (aus dem idmap pool).
Ansonsten fängt ja Linux nichts mit dem Windows-Benutzer bzw. auch einer Windows-Gruppe an.
mal schauen ;)
Manx
PS: netter Erfahrungsaustausch
Bei mir funzt es einfach nicht. Bekomm zwar bei net groupmap list immer was angezeigt, aber das Entspricht dem CN Attribut des Eintrages im LDIF. Manuell mit nett groupmap add ist auch nix zu machen. Poste mal alles. Vielleicht habt Ihr ne Idee...freu mich über Antworten :
linux:/usr/local/samba/bin # ./net groupmap add rid=512 ntgroup="Domain Admins" UNIXgroup=domadm
adding entry for group Domain Admins failed!
linux:/usr/local/samba/bin #
linux:/usr/local/samba/bin # ./net groupmap list
domadm (S-1-5-21-515308762-1151918503-1676858975-512) -> domadm
linux:/usr/local/samba/bin #
dn: cn=domadm,ou=groups,dc=samba,dc=de
objectClass: posixGroup
objectClass: sambaGroupMapping
cn: domadm <--net groupmap list zeit cn Attribut auf beiden seiten.
gidNumber: 1001
sambaSID: S-1-5-21-515308762-1151918503-1676858975-512<--
sambaGroupType: 2
pnuernbe
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.