Benutzerkonto wird bei Aufnahme des Client nicht autoamtisch erzeugt

Guten Abend,

bei der Aufnahme des Clients in meine Domäne ist mir aufgefallen, dass kein Benutzerkonto in der AD angelegt wurde. Bisher war das aber der Fall. Woran kann es liegen? Die AD ist quasi frisch eingerichtet, es wurden keine weiteren Änderungen vorgenommen. Der Server verfügt jetzt allerdings über 4 IP-Adressen. Das Auflösen der DNS und DHCP funktioniert aber einwandfrei.

Danke euch schonmal

Ähm, Nutzerkonten werden nicht automatisch in der AD angelegt!

Du meinst bestimmt, dass auf dem Client bereits Nutzer bestehen und diese dann beim Einfügen des Clients in die AD übernommen werden!?

Das ist nicht der Fall, da es sich um lokale Benutzer handelt die auch weiterhin lokal auf dem Client blieben.

Oder meinst du, dass du dich mit einem Benutzer an der AD anmeldest und kein Profilordner auf dem Server angelegt wird?! Dann fehlen Einträge bei diesem Benutzer im Reiter Profil!

Also ich habe das System auf meinem Client ganz normal angelegt (CLIENT\Benutzer). Dann habe ich über die PC-Eigenschaften den Client zur Domäne hinzugefügt (CLIENT.DOMÄNE). Dann wird man in einem Dialog gefragt, ob man ein Domänen-Konto hinzufügen möchte. Bisher hatte ich dann den Benutzer des Client auf die Domäne übertragen vorgefunden (DOMÄNE\Benutzer), ohen mein Eingreifen. Das heißt es wurde autoamtisch ein Benutzerkonto mit dem Namen des Client-Benutzer ind er Domäne angelegt.

Interessant, diese Abfrage kenne ich z.B. nicht. Bei der Installation erstelle ich einfach einen "unsinnigen" Benutzer (install, test, sonstwas). Nehme dann den Rechner in die Domäne auf. Lokalen Benutzer löschen und Ende. Die Frage kam bei mir noch nie.

Wäre vielleicht gut zu wissen über was für eine Serverversion wir reden ^^

• 2008, 2008 R2, 2012, 2012 R2
• SMB, Standard, Enterprise, Essentials, Homeserver

2012R2 Standard.

Ich bin da echt neu in dem Thema. Nur bisher war es so, und zwar ohne, dass ich am DC was eingestellt habe. Da es jetzt nicht mehr geht, dachte ich das mal wieder irgendwas am System kaputt sei (was ja nicht unwahrscheinlich ist). Wenn es aber die normale Vorgehensweise ist erst einen Benutzer in der Domäne anzulegen und diesen dann nach der Aufnahme des Computers zu übertragen, dann bin ich etwas beruhigt

Das mit dem Übertragen geht eigentlich gar nicht automatisch ... zumindest ist das mein Kenntnisstand. Ich lasse mich gerne auch besserem Belehren
Das fände ich selbst auch sehr interessant Wäre auch interessant wie man den Default User konfigurieren kann (das hin und herkopieren der Benutzerprofile tut ja nicht mehr!).

Ich weiß es nicht Es kann ja sein, dass ich hier generell Quatsch erzähle.

Der Gedanke dahinter: Ich füge einen Client hinzu und habe so direkt ein Benutzerkonto in der Domäne um so die Berechtigungen für Freigaben zu steuern. Das macht es einfacher.
Ich habe zudem das Problem, dass wenn ich eine Freigabe erstelle und die Zugriffsrechte für DOMÄNE\Benutzer zuweise, diese von den lokalen Sicherheitseinstellungen des Laufwerkes übergangen werden. Wenn aud D:\ der DOMÄNE\Benutzer nur Lesen darf, kann ich bei der Freigabe Vollzugriff einstellen wie ich will, der Client kann nichts auf die Freigabe kopieren.

Ich habe mir kurz OpenSuse angeschaut, da kann ich nichtmal eine Festplatte gescheit einbinden - wie man bei Linux überhaupt von einem Betriebssystem, dass steigenden Anteil erhalten soll sprechen kann ist mir schleierhaft. Dieses wahnsinnige Trouble-Shooting bei Windows geht mir allerdings auch auf die Nerven.

Einer der Ideen hinter einer AD ist ja, dass die Clients nicht an Nutzer gebunden sind. Es kann sich jeder überall anmelden und bekommt seine Daten (wenn so eingestellt). Im Kern ändert es am Aufwand nur wenig, ob ich jetzt einen Client einbinde und hierüber einen User erstelle ODER ob ich das direkt auf dem Server mache und mich mit diesem eben dann vom Client aus anmelden kann. Ich persönlich bevorzuge das Vorgehen so wie es ist, schließlich braucht der gute Nutzer ja auch bestimmte Einstellungen wie Profil-Pfad auf Server, Gruppen, Einstellungen, Kennwort usw.

Hier die Abläufe mal visualisiert:

Benutzer auf AD anlegen => Rechte / Einstellungen zuweisen => Benutzer meldet sich am Client an => Fertig

Benutzer meldet sich am Client an => Benutzer wird in AD erstellt => Nachträgliche Konfiguration des Benutzers; Zuweisung der Rechte, Gruppen ...=> Benutzer meldet sich ab => Benutzer meldet sich an => ganz viel Bullshit weil irgendwas nicht funktioniert => Fertig




Das mit der Freigabe ist so auch richtig! Du hast auf 2 Ebenen Rechte zu verwalten:

• Dateisystemebene
• Freigabeebene

Wobei gilt, dass die Dateisystemrechte das letzte Wort haben. Eine so detaillierte Vergabe von Rechten ist mit den Netzwerkfreigaben gar nicht möglich (Attribute, spezielle Berechtigungen, Verweigerungen bestimmter Ordner usw.)

Die Rechteverwaltung ist bei Linux meiner Meinung nach totaler Murks. Die Rechte auf Dateisystemebene sind definitiv nicht für komplexe Rechtevergaben brauchbar, zumindest nicht wenn man die Organisationsstruktur großer Firmen abbilden möchte.
Bei Windows kann man einfach die benötigten Gruppen hinzufügen, bei Linux bräuchte man dafür eine Gruppe die die Gruppen sammelt (da man ja nur einer Gruppe die Rechte zuweisen kann (vielleicht hat sich das ja mittlerweile geändert?)). Sprich man bildet nicht nur die OU in den Gruppen ab, sondern man benötigt auch noch endlos viele "Hilfsgruppen". Da blickt nachher keine Sau mehr durch!

1. Ein DC sollte nicht mehr als ein Netzwerkinterface haben. Falls doch muss man diverse Einstellungen manuell umbiegen, damit es keine Probleme mit dem AD gibt. Stichwort: Multihomed DC.
2. Benutzerkonten werden nicht automatisch im AD angelegt, wenn der Client in die Domäne aufgenommen wird. Die Benutzerkonten sind clientunabhängig, daher wäre so ein Verhalten widersinnig. Die Benutzerkonten müssen vorher im AD angelegt werden.
3. Es ist Best-Practice bei den Freigabeberechtigungen "Jeder - Vollzugriff" auszuwählen und die Rechtesteuerung ausschließlich auf Dateisystemebene zu realisieren.

3. Es ist Best-Practice bei den Freigabeberechtigungen "Jeder - Vollzugriff" auszuwählen und die Rechtesteuerung ausschließlich auf Dateisystemebene zu realisieren.

Zum Vergrößern anklicken....

Naja also die Gruppe "Jeder" ... man könnte sich schon die Mühe machen und die Gruppe "Domänen-Benutzer" oder ähnliche benutzen =)

sini schrieb:

Naja also die Gruppe "Jeder" ... man könnte sich schon die Mühe machen und die Gruppe "Domänen-Benutzer" oder ähnliche benutzen =)

Zum Vergrößern anklicken....

Warum? Was gewinne ich dadurch, wenn ich hinterher auf dem Verzeichnis nur der Gruppe Domänen-Benutzer Zugriff erteile?

Das ist natürlich korrekt und funktioniert. Warum? Ganz einfach, weil man es kann. Ich lasse ja auch nicht die Haustüre offen und schließe nur die einzelnen Räume ab

Frage ich mal so, wieso sollte ich domänenfremde Benutzer (die man ja schon mal im Netzwerk hat) nicht auf oberster Ebene direkt blocken? ^^

Was hast du denn auf dem R2 an Rollen aktiviert? Hast du eventuell statt dem klassischen AD die Essentials-Rolle aktiviert? So ein Verhalten kenne ich nur vom SBS wenn man die connect Webseite aufruft. Schlussendlich sind das Powershell Skripte die im Hintergrund laufen und den ganzen Firlefanz für den Hobbyadmin übernehmen. Dann dürfte es aber auch eine vorkonfigurierte AD-Umgebung mit fertigen OUs geben.
Wäre ja dann die spannende Frage, ob das so beabsichtigt war oder ist.

Also zum Thema Multihomed: Ich möchte, dass der DC unter mehreren Adressen erreichbar ist, denn nur so kann ich SMB-Multichannel überhaupt nutzen. Da die einzelnen Adressen auch im selben Subnetz aktiv sind, glaube ich nicht, dass es da Probleme gibt.

Aktiviert sind im Moment folgende Rollen:

AD DS (nicht die Light - Version)
DNS-Server
DHCP-Server
Dateiserver

Also eine ganz schmale Installation.

Beabsichtigt ist, dass der Server ein paar Dienste bereit stellt und als Speicherort für Dateien Dient. Dieses Ganze mit AD und DNS ist ndabei natürlich nicht fundamental wichtig, aber ich denke es ist unheimlich nützlich, wenn es funktioniert.
Das Problem ist, dass ich über das was die AD macht nicht wirklich eine Übersicht habe. In den Tools von DNS und DHCP sehe ich egnau, welche Schnittstellen wie konfiguriert sind. Bei der AD im Verwaltungscenter habe zwar eine Übersicht über die Benutzer und Computer in der Domäne, aber nicht über Dienst selber. Als ich den Server nur mit einer IP-Adresse betrieben habe gab es diese Probeme komischwerwise nicht.

ML89 schrieb:

Das Problem ist, dass ich über das was die AD macht nicht wirklich eine Übersicht habe. In den Tools von DNS und DHCP sehe ich egnau, welche Schnittstellen wie konfiguriert sind. Bei der AD im Verwaltungscenter habe zwar eine Übersicht über die Benutzer und Computer in der Domäne, aber nicht über Dienst selber.

Zum Vergrößern anklicken....

Was genau fehlt dir denn an Informationen, was erwartest du zu sehen? SMB-Multichannel kannst du übrigens auch mit NIC-Teaming betreiben, da genügt dann eine IP-Adresse. Aber solange alle deine IPs im gleichen Subnetz sind, dürfte es keine Probleme geben. Wichtig ist nur, dass alle IPs des DC immer im DNS auflösbar sind.

Evil E-Lex schrieb:

SMB-Multichannel kannst du übrigens auch mit NIC-Teaming betreiben, da genügt dann eine IP-Adresse.

Zum Vergrößern anklicken....

Habe es ausprobiert. Die 4 Anschlüsse des Servers zu einem gebündelt funktioniert, wenn der Client weiterhin 2 Anschlüsse hat. Bündle ich die des Client zu einem habe ich keinen Multichannel mehr

Da könnte ich doch glatt im Strahl Kotzen! Jetzt geht gar nix mehr. Der Client findet weder den DNS-Server noch das Netzwerk noch sonst irgendwas. Gebe ich dem Client eine statische IP-Adresse funktioniert die Namensauflösung aller 4 IP-Adressen des Servers.