PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Domänenbenutzer-Hauptbenutzer-Problematik



michaxyz
20.08.08, 09:19
Hallo miteinander,

lange nichts von mir gehört, jetzt brauch ich selbst mal wieder Hilfe.

Ich beutze samba 3.0.28a (ubuntu hardy server). Dachte, ich bräuchte mal frischen Wind, ich hatte vorher Debian Sarge.
Nun zum Problem: Früher hatte ich in die Gruppe der Hauptbenutzer die Gruppe der Domänenbenutzer aufgenommen. Von da ab (so erscheint es mir jedenfalls) konnte ich im Loginscript Drucker per con2prt zuweisen.
Jetzt habe ich das auch probiert und bin zunächst darauf gestoßen, dass es diese Gruppe noch gar nicht gab.
1. Frage: Ist das gelöst dadurch, dass ich die mit Namen "Domain Users" und der RID 513 auf users mappe oder komme ich auch ohne das Mappen aus?
2. Trotzdem die Hauptbenutzergruppe die Gruppe Domain Users enthält, können Benutzer beim Anmelden keine Drucker per con2prt zugewiesen bekommen. Der Testbenutzer hat NICHT die primäre Gruppe users (worauf Domain Users gemappt wurde).

Zusätzliche Infos: Clients: Win 2k
Samba als PDC
Werden weitere Infos benötigt? Kann ich selbst in den Logs was lesen? /var/log/samba/log.nmbd ist genauso wenig hilfreich wie ./log.smbd gewesen.

Vielen Dank im Voraus!

Mfg Michael

pireli
20.08.08, 19:18
Hallo,

ich würde es mit Gruppen-Mapping versuchen, wie du schon gesagt hast. Ein Hauptbenutzer darf Drucker installieren. Die Gruppe die du möchtest auf RID 513 und es müsste gehen.

Die Unixgruppe die "Domainbenutzer" sein sollten musst du mappen das kann z.B. users sein oder auch einen anderen Namen.

Vielleich irgendwelche Gruppenrichtlinien aktiv die das verhindern???

michaxyz
21.08.08, 11:14
Hallo pireli,

danke erstmal für deine Antwort.
Welche Gruppenrichtlinie könnte das denn verhindern? Ich baue da zwar eine (aus der alten config stamennde) ntconfig.pol ein, was da aber drin steht, weiß ich nicht mehr. So was wie profile nachher wieder löschen, eigene Dateien auf \home mappen und so ein Zeugs. Aber: die hatte ich früher auch.
Irgendwelche Ideen?

Anbei, seit gestern ist mir in /var/log/daemons.log der Eintrag:



Aug 21 12:03:13 server winbindd[11774]: [2008/08/21 12:03:13, 0] nsswitch/idmap.c:idmap_alloc_init(750)
Aug 21 12:03:13 server winbindd[11774]: ERROR: Initialization failed for alloc backend, deferred!
Aug 21 12:03:13 server smbd[30236]: [2008/08/21 12:03:13, 0] auth/auth_util.c:create_builtin_administrators(792)
Aug 21 12:03:13 server smbd[30236]: create_builtin_administrators: Failed to create Administrators
Aug 21 12:03:13 server winbindd[11774]: [2008/08/21 12:03:13, 0] nsswitch/idmap.c:idmap_alloc_init(750)
Aug 21 12:03:13 server winbindd[11774]: ERROR: Initialization failed for alloc backend, deferred!
Aug 21 12:03:13 server smbd[30236]: [2008/08/21 12:03:13, 0] auth/auth_util.c:create_builtin_users(758)
Aug 21 12:03:13 server smbd[30236]: create_builtin_users: Failed to create Users

aufgefallen. Ich habe in dem Log keine Angaben erwartet, habe es daher erst jetzt entdeckt. Ist das vielleicht ein Hinweis?

Ich könnte hier wirklich gut Hilfe gebrauchen...

Mfg Michael

michaxyz
21.08.08, 11:57
Hi, wollte nichts ändern, nur ergänzen.

Die Fehlermeldung habe ich abstellen können. Winbind benötige ich gar nicht.
Hauptproblem bleibt immer noch: Wenn ich users in die Gruppe der Hauptbenutzer aufnehme (lokal) können sie z.b. keine Drucker bekommen. Werden sie in die Gruppe der Administratoren (lokal) aufgenommen, geht das. Aber das ist kein Zustand.

Ich teste demnächst mal das weglassen der ntconfig.pol, vllt gehts ja dann. Ich hege aber wenig Hoffnungen, früher haben wir die ja auch gehabt.

Könnte es an SP4 liegen?

Mfg Michael

UzumakiNaruto
21.08.08, 12:32
SP 4 sollte solche probleme nicht bereiten und windows benötigt dieses SP auch unbedingt ;) sonst kannste z.b. den dieses SP hebt die beschränkung bei HDDs über 128 GB auf ;)

gucke mal in den lokalen sicherheitsrichtlinien was dort eingestellt ist .. dort kann man ja fast jeden quatsch einstellen, welche gruppe was genau darf und was nicht ;)

Start -> ausführen

gpedit.msc
Computerkonfiguration -> Windows-Einstellungen -> Sicherheitseinstellungen -> Lokale Richtlinien -> Zuweisen von Benutzerrechten

OT: der support für windows 2000 ist aber schon lange vorbei .. die hacker freuen sich sicherlich systeme mit sicherheitslücken vorzufinden die microsoft nie schließen wird ;)

michaxyz
22.08.08, 10:42
Hallo UzumakiNaruto,

danke für deine Antwort.
Leider finde ich nichts auffälliges darin. Die Hauptbenutzer werden nur ein paarmal erwähnt, bei den Richlinien
Ändern der Systemzeit
Auf Diesen Computer vom Netzwerk zugreifen
Auslassen der durchsuchenden Überprüfung
Entfernen des Computers von der Dockingstation
Herunterfahren des Systems
Lokal anmelden
Erstellen eines Profils für einen Einzelprozess

Ich habe wirklich keinen Schimmer, wonach ich da suchen kann. Die anderen Richtlinien scheinen mein Problem nicht zu treffen. Ach ja, die effektiven Einstellungen scheinen mit den lokalen übereinzustimmen.

Vielleicht beginne ich noch mal etwas weiter vorn...
Nach der Installation des Systems trete ich in die Domäne ein, nehme eine Domänengruppe, die auf alle Benutzer meiner Domäne gemappt ist, in die lokale Gruppe Hauptbenutzer auf. Dann sollten Fehlermeldungen beim login a la \\Server\\Drucker konnte nicht gefunden werden nicht mehr vorkommen, es sei denn, Drucker ist nicht von Server freigegeben, oder?

Mfg Michael

PS: Unsere Systeme sind mit Wächterkarten gesichert, das sollte also nicht das Problem sein. Wäre es das trotzdem, hätte ich wenigstens einen Grund, auf Linux umzusteigen. ;-)

michaxyz
25.08.08, 17:10
Hallo miteinander,

ich habe mittlerweile neue Erkenntnisse. D.h. wohl Infos, die ich für irrelevant gehalten habe, die es aber nicht sind.

Ich stelle vor allem noch mal die Situation kurz dar: Ich bin mit meinem PDC von Samba 2 auf samba 3 umgezogen, wobei ich dachte, die Konfiguration (d.h. /etc/samba) kopieren zu können. Das habe ich auch gemacht. Außerdem habe ich das Profileverzeichnis einfach kopiert.

Nun habe ich folgende Situation bei den Clients: Ich habe die Unixgruppe admins auf die RID 512 gemappt (Name: Domänenadministratoren) und in die Gruppe der lokalen Administratoren aufgenommen. Klappt ganz gut, der domäne\administrator kann Admin-Aufgaben ausführen.

Außerdem habe ich die Gruppe users auf die RID 513 (Name: Domänenbenutzer) gemappt und lokal in die Gruppe Hauptbenutzer verfrachtet.
Bisher konnte ich keinen Erfolg erkennen, da alle Nichtmitglieder der Gruppe admins beim Ausführen des Startscripts Fehler aufwiesen. Das Startscript versucht einige Reg-Einträge per regedt auszuführen. Außerdem werden die Drucker nicht verbunden.
Ab heute (ich habe mal einen alten Client genommen, bin aus der Domäne raus, in die aktuelle rein, Gruppen wie oben lokal zugefügt) gibt es eine Änderung: ich habe von Testbenutzern die Profile gelöscht. Ich habe da zwei Kategorien: Schüler und Lehrer (ja, sorry, ich bin Lehrer). Bei den Lehrern läuft jetzt das Script durch (auch beim neu aufgesetzten Client, erst seitdem ich das Profil gelöscht habe). Bei den Schülern nicht, wie gehabt Fehler beim Scriptdurchlauf bei den Regs und den Druckern.

Hat da jemand mal eine gute Idee, was ich noch probieren könnte? Ein vorheriger Vorschlag eine alte Gruppenrichtlinie könnte das Problem sein, erscheint mir daher unwahrscheinlich (habe einen alten Client und einen neuen getestet).

Alternativ: Gibts Tippt, wie ich die Profile migrieren kann? Ich weiß, das kann ich noch suchen, bin aber ungeduldig.
Danke im Voraus für die Tipps!

Mfg Michael

michaxyz
27.08.08, 09:55
Hallo miteinander,

nochmals vielen Dank für alle Hilfe hier im Forum.
Mittlerweile hat sich die Ursache meiner Probleme gezeigt: die SID hat sich trotz aller Umsicht beim Update (Hard- und Software) geändert. Daher wurden die Profile nicht so wirksam, wie ich mir das vorgestellt habe.
Irgendwie stand in der ntuser.dat der Benutzer noch die alte SID drin.

Lösung besteht erst einmal aus der Brachialmethode, die Profile zu löschen, sodass sich die Benutzer neue holen müssen. Dafür musste das Default-Profile aktualisiert werden.

Im Moment laufen noch Tests, ob es reicht, die ntuser.*-Dateien uz aktualisieren. Wenn Bedarf besteht, kann ich über den Erfolg berichten.

Andererseits wäre ich noch mal über einen Tipp dankbar, wie man im Falle eines Updates clever vorgeht, damit das Problem umgangen werden kann.

Mfg Michael