[Astorek]

Hi @ all,

Vorneweg, ich nutze den SBS 2011 Standard mit SP1 - da dieser auf den Windows Server 2008 basiert, dachte ich, dass das hier der richtige Forenzweig für den Thread wäre^^.


Zu meinem Problem: Eine Batch-Datei sorgt beim Aufruf dafür,

• dass ein neuer Nutzer in der Domäne angelegt wird,
  
• ein Ordner in einer Freigabe angelegt wird,
  
• und Rechte auf den Ordner gesetzt werden, die den soeben angelegten Benutzer betreffen

Führe ich die Batch-Datei direkt auf dem Server aus, gibt es absolut keine Probleme, alles läuft einwandfrei.

Die Batch-Datei soll aber auch von Client-PCs aus ausgeführt werden - zu diesem Zweck bietet Microsoft ja RSAT (Remoteserver-Verwaltungstools) an, die typische Konsolenprogramme wie dsadd etc. nachrüstet. Die Batch selbst wird selbstverständlich IMMER mit Admin-Rechten ausgeführt.

Und hier habe ich in etwa 3 von 10 Fällen das Problem, dass zwar die Rechte korrekt gesetzt werden - allerdings auf ein "Unbekanntes Konto". Was mich dabei absolut ratlos macht: Es geschieht in meinen Augen absolut zufällig! Wenn ich 10x hintereinander mit der Batch-Datei denselben Nutzer anlege, klappt das vielleicht 2-3x nicht. Der angelegte Benutzer hat dann natürlich keinerlei Zugriff auf ebenjenen Ordner, existiert so aber im AD...

Hat zufällig irgendjemand eine Idee, woher der Fehler mit dem "unbekannten Konto" herkommt? Der einzige Zusammenhang ist, dass das Problem nur bei Client-PCs mit RSAT auftritt. Aus diversen Gründen kann ich auf RSAT nicht verzichten.

Tjoar... Irgendjemand eine Idee? Mir sind die ehrlichgesagt komplett ausgegangen^^.

Der Vollständigkeit halber auch noch die Batch-Datei, falls sich das einer antun will^^:

Spoiler

@echo off
SETLOCAL ENABLEEXTENSIONS
:: BESCHREIBUNG
:: ============
:: Legt einen Benutzer in der angegebenen OU an und erstellt im passenden Ort
:: ein Verzeichnis, dem die Gruppenrechte entzogen und die Benutzerrechte
:: hinzugefuegt werden, nachdem die Vererbung im Ordner deaktiviert wurde.
::
::
:: PARAMETER
:: =========
::  %1 = Nachname OHNE Anführungsstriche!
::  %2 = Vorname OHNE Anführungsstriche!
::  %3 = Passwort
IF "%1"=="/?" GOTO help
IF "%1"=="" GOTO help
IF "%2"=="" GOTO help
IF "%3"=="" GOTO help


SET LN=%1
SET FN=%2
SET pwd=%3


:: Setze die Ordnervariable an die richtige Stelle (für mkdir und icacls wichtig)
:: ==============================================================================
SET homedir="D:\Daten\%LN%_%FN%"


:: Bereich, in dem der User angelegt wird
:: ======================================
SET OU="CN=%LN%_%FN%,OU=Benutzer,OU=Schulung,DC=ssbs,DC=local"


:: In welcher Domain soll der Benutzer angelegt werden?
:: ====================================================
SET UPN="%LN%_%FN%@schulung.local"


:: Weitere Einstellungen für dsadd...
:: ==================================
SET params=-canchpwd no -pwdneverexpires yes -disabled no


:: Gruppenzugehörigkeiten festlegen
:: ================================
SET GRP="CN=GlobaleGruppe,OU=Gruppen,OU=Schulung,DC=ssbs,DC=local"


:: SAM-ID anlegen (Windows erlaubt max. 20 Zeichen)
:: ================================================
SET SAMTMP=%LN%_%FN%
SET SAMID=%SAMTMP:~,20%


:: Befehle schlussendlich ausführen: User erstellen
:: ================================================
DSADD USER %OU% -loscr %LOGON% -samid "%SAMID%" -upn %UPN% -fn "%FN%" -ln "%LN%" -pwd %pwd% %params% -memberof %GRP%


:: Verzeichnis erstellen, Vererbung ausschalten aber die derzeitigen Rechte übernehmen
:: ===================================================================================
MKDIR %homedir%
ICACLS %homedir% /inheritance:d


:: Gruppe "GlobaleGruppe" die Rechte entziehen und dem Benutzer Schreibrechte gewähren
:: ===================================================================================
ICACLS %homedir% /remove GlobaleGruppe
ICACLS %homedir% /grant %UPN%:(OI)(CI)(RX,W,DC)
GOTO ende


:help
ECHO Erstellt vollautomatisch einen neuen Benutzer in der AD samt Ordner fuer ihn.
ECHO.
ECHO %0 ((Nachname) (Vorname) (Passwort)
ECHO.
ECHO Stimmt ein Parameter nicht, wird diese Hilfe angezeigt.
ECHO.
ECHO Fuer weitere Informationen, einfach die Batch-Datei selbst
ECHO ansehen, sie duerfte relativ selbsterklaerend sein.
ECHO.
GOTO ende


:ende

Dieser Beitrag wurde von Astorek bearbeitet: 01. Oktober 2014 - 08:15

[RalphS]

- Du kannst mit %~... Anführungszeichen wegwerfen. So kriegst Du auch "Hans Peter Müller" unter (müßtest dann aber natürlich die Leerzeichen aus der samID werfen) und SET FN=%~1 plus SET LN=%~2 gibt dann FN mit dem Wert [Hans Peter] und LN mit Wert [Müller].

- Hast Du mehrere DCs vor Ort? Das klingt so ein bissel nach einem Replikationsproblem, daß der neue User einfach noch nicht überall angekommen ist.

- Du könntest Dir mit

dsquery * "CN=%LN%_%FN%,CN=Benutzer,...,DC=local" -attr objectSID

die SID besorgen: entweder das klappt und Du hast die richtige oder aber es klappt nicht, dann würd ich sagen sollte es reichen, ein paar Sekunden zu warten (über irgendein Timeout).

Hab mir jetzt die icacls Syntax nicht nochmal genau angeschaut, mir war aber so, als ob man da auch die SID statt des Namens nehmen konnte. Damit sollte das zweifelsfrei sein, wenn Du Dir diese bereits beschafft hast.


Hinweis: die ds*** Befehle sind mehr oder weniger als deprecated anzusehen; gut möglich, daß die "relativ bald" nicht mehr unterstützt werden. Wäre also eine Überlegung wert, bevor die Batch zu groß wird, gleich auf PowerShell umzuschwenken. Die entsprechenden Befehle stecken im ActiveDirectory-Modul (*-AdUser) und in Microsoft.PowerShell.Security (*-Acl) und falls die nicht reichen sollten, kommt man über WMI an den Rest.

[Astorek]

Zitat (RalphS: 12. September 2014 - 12:19)

- Du kannst mit %~... Anführungszeichen wegwerfen.

Prima, kannte ich noch garnicht. Danke für den Tipp!

Zitat

- Hast Du mehrere DCs vor Ort? Das klingt so ein bissel nach einem Replikationsproblem, daß der neue User einfach noch nicht überall angekommen ist.

"Leider" nein, es existiert nur ein einziger Server, der als DC agiert.

Zitat

SID

Auch hier: Danke für den Tipp, das Problem konnte ich jetzt noch weiter eingrenzen . Ich hatte vergessen zu erwähnen, dass ich mit der Batchdatei immer mal wieder denselben User (also mit demselben Vor- und Nachnamen, Gruppenzugehörigkeit etc.) generiert und dann händisch wieder gelöscht habe. Ich hab jetzt folgendes herausgefunden: Wenn ich per Batch DSQUERY aufrufe, wird mir die SID eines Users zurückgegeben, den ich zwar angelegt, aber mittlerweile wieder gelöscht habe (vermutlich, weil der gelöschte User eben denselben Vor- und Nachnamen, UPN etc. hat). Scheinbar hat der Server beim Löschen und neu Anlegen des Benutzers noch nicht realisiert, dass sich bei besagtem User auch die SID geändert hat... Sogar nach ca. 15-minütiger Wartezeit wird mir immernoch die "alte" SID zurückgegeben...

Scheint wohl ein Bug in RSAT zu sein, oder?^^ Wär ziemlich blöd, da die Batch-Datei Teil eines Programms ist, die ich weniger versierten Anwendern in die Hände drücken möchte und da nicht ausgeschlossen ist, dass diese mal aus irgendwelchen Gründen mehrmals denselben Nutzer löschen und wieder neu anlegen^^...

Zitat

Hinweis: die ds*** Befehle sind mehr oder weniger als deprecated anzusehen; gut möglich, daß die "relativ bald" nicht mehr unterstützt werden. Wäre also eine Überlegung wert, bevor die Batch zu groß wird, gleich auf PowerShell umzuschwenken. Die entsprechenden Befehle stecken im ActiveDirectory-Modul (*-AdUser) und in Microsoft.PowerShell.Security (*-Acl) und falls die nicht reichen sollten, kommt man über WMI an den Rest.

Vielen Dank für die Info . Ich behalts im Hinterkopf, sollte es jemals zu aufwändig werden^^...

Dieser Beitrag wurde von Astorek bearbeitet: 15. September 2014 - 12:11

[RalphS]

Mh... das klingt so, als ob da die LDAP-Abfrage in irgendeinen Cache wandern würde.

Hab leider grad keinen Zugriff auf DCs... und mir war zwar so, als ob da bei dsquery nichts zwischengespeichert würde, aber "irgendwoher" muß ja das nun gelöschte Objekt herkommen.

Gibt's denn das richtige Objekt zurück, wenn Du nach -attr objectSID suchen läßt? Oder gibt es dann gar kein Ergebnis?

[Astorek]

Erstmal Sorry, dass ich erst jetzt wieder antworte. Mittlerweile habe ich das Problem - zugegeben ziemlich unelegent^^ - gelöst: Von SysinternalsSuite gibts ja "PsExec", mit dem man Konsolenbefehle remote ausführen kann. Ich hab das Problem jetzt so gelöst, dass sowohl das Anlegen des Benutzers als auch das Setzen der Verzeichnisrechte über PsExec stattfinden. Natürlich "darf" dabei nichts schiefgehen, aber zuverlässiger als die vorherige Methode ist es bisher allemal - zumal ich PsExec nur in sehr geringem Maße einsetze^^.

:: Befehle schlussendlich ausführen: User erstellen
:: ================================================
PsExec \\[server-ip] -u [server-ip]\Administrator -p [pw] DSADD USER %OU% -loscr %LOGON% -samid "%SAMID%" -upn %UPN% -fn "%FN%" -ln "%LN%" -pwd %pwd% %params% -memberof %GRP%

[...]

:: Gruppe "GlobaleGruppe" die Rechte entziehen und dem Benutzer Schreibrechte gewähren
:: ====================================================================================
ICACLS %homedir% /remove GlobaleGruppe
PsExec \\[server-ip] -u [server-ip]\Administrator -p [pw] ICACLS %homedir% /grant %UPN%:(OI)(CI)(RX,W,DC)
GOTO ende

Bisher ist mir die Änderung (wird seit ca. 2 Wochen aktiv verteilt) noch nicht um die Ohren geflogen und bisher hat sich auch noch keiner beschwert, dass irgendwas nicht läuft. Ich geb zu: Eine "schöne" Lösung ist was anderes, und ich fange erst jetzt wieder an, Nachts einigermaßen beruhigt zu schlafen. Aber bisher lief über diesen Workaround alles so, wie ich es mir vorstelle^^...

Zitat (RalphS: 15. September 2014 - 19:44)

Gibt's denn das richtige Objekt zurück, wenn Du nach -attr objectSID suchen läßt? Oder gibt es dann gar kein Ergebnis?

Weil mir das keine Ruhe gelassen hat, hab ichs mir nochmal angesehen, und jetzt wirds wirklich interessant: Wenn ich direkt auf dem Server nach der "alten" SID suchen lasse, findet er keine Benutzer - dann aber der Client mit installiertem RSAT auch nicht mehr. Sobald ich auf dem Server nach der "alten" SID suchen lasse, klappt auch das Batch-Skript vollständig. Allerdings - jetzt kommts - funktioniert das NICHT, wenn ich nach der "neuen" SID suche, obwohl er mir dann das richtige Ergebnis liefert! Trotz korrekt erkannter SID setzt ICACLS die Rechte für die "alte" SID, außer ich suche vorher explizit nach der "alten" SID! Ich habs gut ein paar Dutzend Male probiert und bin immer wieder auf dieses Problem gestoßen... Sehr seltsam, das alles^^.

Ich könnte natürlich auch eine Art Datenbank pflegen, in der ich alle jemals angelegten Benutzer samt SID speichere und beim Neuanlegen eines Users mit demselben Vor- und Nachnamen dann die "alte" SID überprüfen lasse. Allerdings wär mir das ein zu großer Workaround für das Problem; da würde locker mal ein halber oder ganzer Arbeitstag deswegen wegfallen, bis ich sowas programmiert habe^^.

Anyway: Mein Problem ist durch den Workaround gottseidank auch gelöst worden. Natürlich trotzdem auch Danke für deine Hilfe.

(+1 auf meine "seltsame Phänomene in Windows"-Liste...)

Dieser Beitrag wurde von Astorek bearbeitet: 01. Oktober 2014 - 08:17