olc

Hi, bei einem PING bekommst Du immer "irgend einen" DC zurück - genauer einen DNS Server, der die Zone der Domäne hostet. Wenn Du die korrekte Auflösung nachstellen möchtest, die ein Client zur Lokalisierung eines DCs verwendet, dann benötigst Du eine Abfrage über die API "DsGetDcName". Am einfachsten erreichst Du das über ein am Client ausgeführtes: NLTEST /DSGETDC:[b]NETBIOS_NAME_DEINER_DOMAIN[/b] Generell: Subnetzinformationen sind korrekt in den Sites & Services gepflegt? Viele Grüße olc

Gern, bei Fragen melde Dich hier bei uns. :) Viele Grüße olc

Hi, wenn Du es wie beschrieben durchführst, bleiben alle mit dem alten Schlüsselpaar ausgestellten Zertifikate gültig. Kein Problem also. :) Auch, wenn Du den privaten Schlüssel erneuern würdest, wären sie weiter gültig. Es werden dann nur zwei (oder langfristig mehr) CRLs ausgestellt. Also auch das wäre kein Problem. Wichtig ist nur, daß das Zertifikat der Root-CA im "Trusted Root Certificate Authorities" Speicher der PKI-Clients enthalten ist / bleibt. Gehst Du wie im Link beschrieben vor und machst keine weiteren Aktionen, bleibt hier auch alles im grünen Bereich. Viele Grüße olc

Oh, ok - mein Fehler. Du ersetzt ja gar nicht den Pfad in der Registrierung, sondern nutzt das nur als Variable, um Dich remote auf das System zu begeben, korrekt? $remoteprofilepath = ("\\$server\$profilepath").replace('C:','c$') Dann nehme ich alles zurück und behaupte das Gegenteil. ;) P.S.: Mit dem Snippet oben kannst Du Dir PsGetSID sparen. Du kommst mit .NET / PowerShell direkt an die SID ran. P.P.S.: Denk auch daran, daß wenn Ihr die GPOs nicht selbst unter Kontrolle habt, über die IE Maintenance meines Wissens auch Favoriten verteilt werden können. Nicht, daß Du mit den Einstellungen und dem Kopiervorgang Probleme verursachst. Viele Grüße olc

Hi, vor dem Problem stand ich auch einmal und habe es genauso lösen müssen wie Du jetzt (hier ein paar Snippets): Zuerst die SID auflösen ($username als Parameter übergeben): function ConvertTo-SID($username) { $SID = new-object system.security.principal.NtAccount($UserName) $SID = $SID.translate([system.security.principal.securityidentifier]) $SID.value.ToString() } Invoke-Expression "Set-Variable -Name UserName -scope script -value $UserName" Dann prüfen, ob ein entsprechendes Profil des Benutzers auf dem aktuellen System vorhanden ist: Test-Path "Microsoft.PowerShell.Core\Registry::HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\$UserSID" Danach kannst Du dann die Eigenschaften entsprechend prüfen: $UserProfilePath = (Get-ItemProperty -path "Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\$UserSID" -name "ProfileImagePath").ProfileImagePath EDIT: Oh, ok. Da warst Du mit dem Posten schneller als ich mit dem Zusammensuchen der Snippets. :) EDIT 2: Und jetzt wo ich sehe, wozu Du es benötigst: Das Vorgehen von Dir ist nicht von MS supported. Klar, wird Dir egal sein, aber es ist wichtig zu wissen. ;) Viele Grüße olc

Hi, wie jarazul schrieb - nur bei "certificate hold" kannst Du das Zurückziehen des Zertifikats rückgängig machen. Aber einmal anders gefragt: Wozu wird das Zertifikat verwendet? Entschlüsseln kannst Du auch nach einer Revozierung, für Signaturen stellst Du einfach ein neues Zertifikat aus. Gibt es einen konkreten Grund, warum das alte Schlüsselpaar genutzt werden soll? BTW: Ihr könnt bei der Gelegenheit auch einmal Eure Prozesse überdenken ;) - ein Zertifikat sollte nicht gesperrt werden, wenn es nicht wirklich zurückgezogen werden soll... :p Viele Grüße olc

...oder Ihr überdenkt Euer Software Verteilungssystem: So könnte man entweder mittels SCCM oder ähnlichen Lösungen "self-provisioning" Systeme einrichten, die etwa nach einem Neustart eine Software installieren oder aber Ihr könntet gleich auf Virtualisierung setzen (Terminalserver, App-V, Med-V usw.). Fakt ist, daß diese "mach mich Admin, mach mich nicht Admin" Geschichte von Design her nicht funktionieren kann. Das wäre wie "die Hand vor die Augen halten, um nicht gesehen zu werden." :) Viele Grüße olc

Hi, Du kannst keine doppelten SIDs in der Domäne finden ;) - jedoch können sich mehrere Computer ein Computerkonto (=eine "SID") unfreiwillig "teilen". Dadurch würden immer wieder die Kennwörter der Rechner zurückgesetzt. Noch einmal nachgefragt: Wie werden die Rechner genau installiert? Werden diese z.B. nach Aufnahme in die Domäne gecloned? Viele Grüße olc

Hi, einmal Admin, immer Admin. Habe ich erst einmal Zugriff auf ein System, kann man mir die Berechtigungen nicht mehr entziehen. Aus meiner Sicht ist das Vorgehen der falsche Ansatz: Was genau müssen die Entwickler auf den Systemen denn "konfigurieren", so daß sie Admin-Berechtigungen benötigen? Viele Grüße olc

Hi nochmal, abgesehen davon (siehe auch die anderen kommentare), daß ich das Vorgehen nicht für sinnvoll halte - nur der Vollständigkeit halber: So sollte es funktionieren. @echo on set a=abcd %logonserver%\netlogon\whoami.exe /groups | findstr /I "\<%a%" ::Gruppe nicht gefunden if errorlevel == 1 echo Gruppe %a% nicht gefunden ::Gruppe gefunden if errorlevel == 0 echo Gruppe %a% gefunden Viele Grüße olc

Hi Stephan, gern. :) Genau, nachdem Du das Issuing CA Zertifikat mit dem korrekten AIA und CDP Verteilungspunkt angepaßt und die Issuing CA Konfiguration für von der Issuing CA ausgestellte Zertifikate abgepaßt hast, kannst Du entweder die alten Zertifikate zurückziehen. Alternativ (und das halte ich in Deinem Szenario für sinnvoller) kannst Du das Autoenrollment prüfen, ob "alle Haken" in der entsprechenden Gruppenrichtlinie gesetzt sind und danach über ein "Reenroll all certificate holders" das Reenrollment auslösen. Wenn die DCs selbst noch Windows Server 2003 sind, mußt Du die DCs dann (nacheinander) neu starten. Sind es Windows Server 2008 und aufwärts DCs, übernehmen sie die Änderung im Laufbetrieb. Kann etwas dauern, also keine Hektik. ;) Siehe dazu - Configure Autoenrollment in Group Policy (ich würde nur nicht unbedingt die Default Domain Policy nehmen, kommt auf Deine derzeitige Konfiguration an - wichtig sind die beiden Haken ganz unten im Artikel) - Re-enroll all certificate holders: Public Key Viele Grüße olc

Hi Stephan, ich meine es nicht böse wenn ich sage, daß Du Dich noch einmal ein wenig mehr in das Thema PKI einlesen solltest. :) Brian Komar hat da beispielsweise ein recht gutes Buch veräffentlich. :) Die AIA und CDP steht jeweils im Zertifikat, egal ob Root CA, Intermediate / Issuing CA oder Enduser. Wenn Du Dir das Zertifikat der Root CA anschaust und keine AIA und CDP darin findest, mußt Du das Root CA Zertifikat nicht erneuern. Das heißt der Teil der CAPolicy.inf fällt weg. Bleiben also noch Intermdiate / Issuing CA und Enduser. Um das Intermdiate / Issuing CA Zertifikat zu erneuern, mußt Du in der CA Konfiguration der Root CA die Verteilungspunkte anpassen. Danach stellst Du dann wie im Artikel beschrieben ein neues Intermdiate / Issuing CA Zertifikat aus. Danach änderst Du auf der Intermdiate / Issuing CA die Verteilungspunkte in der CA Konfiguration und stellst neue Endbenutzer Zertifikate aus. P.S.: Bei Dir handelt es sich um eine "Issuing CA", keine "Intermediate CA", es sei denn Du hättest 3 Ebenen der CA Hierarchie ohne Endbenutzer. Viele Grüße olc

Hi, Ich habe *zwei* mögliche Szenarien genannt - die Antwort "ja" hilft also nicht wirklich weiter... ;) AIA und CDP anpassen in der CAPolicy.inf Datei. Beides auf "empty" setzen und danach Root CA Zertifikat erneuern: [AuthorityInformationAccess] Empty=True [CRLDistributionPoint] Empty=True *Zuerst* die AIA und CDPs auf der Root CA anpassen, danach erst das Zertifikat der Zwischenzertifizierungsstelle erneuern. Zertifikat erneuern ohne den privaten Schüssel zu erneuern siehe: Renew a subordinate certification authority: Public Key Korrekt. Vorher prüfen, ob die AIA und CDP nun korrekt ist / sind. Am besten Du entfernst erst einmal alle Templates von der CA, so daß nicht zwischenzeitlich irgend etwas ausgegeben wird. BTW: Eine Testumgebung ist mehr als sinnvoll, Du operierst hier im Moment ja scheinbar am offenen Herzen... Viele Grüße olc

Hi Stephan, was heißt "die Namen sind gleich"? Was meinst Du damit genau - hast Du die Verteilungspunkte inkl. der konkreten CER und CRL Dateien vollkommen gleich benannt, so daß kein Unterschied mehr zum Abruf existiert? Meinst Du in Bezug auf AIA und CDP oder in Bezug auf die Root und Intermediate CAs? Verändern kannst Du ein Zertifikat nachträglich nicht mehr, Du müßtest also (falls notwendig) neue Zertifikate erstellen. Du benötigst dafür *keinen* neuen privaten Schlüssel, Du kannst lediglich das Zertifikat mit den korrekten Verteilungspunkten neu erstellen. BTW: Im Root / Stamm Zertifikat sollte keine AIA und keine CDP stehen. Erst ab der ersten untergeordneten CA (bzw. deren Zertifikat), sollten AIA und CDP zur Verfügung stehen. Viele Grüße olc

...mit den GPP kannst Du ja Gruppen als Filter nutzen. ;) Deshalb der Hinweis von Sunny61 zum zweiten Screenshot auf der verlinkten Webseite... :) Versuche es einmal mit den GPP, wenn Deine Betriebssysteme Windows XP aufwärts sind - ggf. noch das GPP Update vorher auf XP und Vista installieren (etwa per WSUS). Du wirst sehen, daß das weit einfacher und komforabler ist als das Logon Script. Ansonsten: Versuch es einnmal im Scipt ohne Leerzeichen: findstr \<%a% Das %a% wird korrekt im Script aufgelöst? Viele Grüße olc

Hi Daniel, Ja, das ist ein guter Ansatz. Auf dem Client erledigt der NETLOGON Dienst die Abfrage, der DC / DFS-Root Server nutzt jedoch AFAIR für die Generierung der Referral-Liste den Workstation Dienst. Und genau da kann ein Problem liegen, je nach Konstellation. Na ja, dann hast Du die Ursache vermutlich gefunden... ;) Der Client fragt wie oben schon beschrieben nach einem DC der eigenen Site - der DCLocator ist hierfür verantwortlich. Wenn der Client jedoch selbst nichts von seinem Subnetz weiß (bzw. nicht wissen kann, da kein Domänenmitglied), bekommt der Client irgend einen generischen DNS Eintrag für einen "beliebigen" DC zurück. An den DC wendet der Client sich dann und bekommt u.a. über den Workstation Service des DFS-Root Server (in dem Fall der DC selbst) den entsprechenden Verweis. Der DC gibt hierbei einen DC der eigenen Site zurück, hier ist es also schon zu spät. Versuche einmal folgendes: Setze auf den nicht-Domänen-Clients einmal den folgenden Registry Schlüssel, als Wert der Name Deiner Site1: Schlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters REG_SZ (falls nicht vorhanden bitte erstellen): SiteName Wert: Site1 Siehe dazu auch: Finding a Domain Controller in the Closest Site Danach sollte der nicht-Domänen-Client beim richtigen DC in Site1 landen. Viele Grüße olc

...genau das sagt der KB-Artikel. ;)

Hi Mario, schau einmal hier hinein: How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003 and from Windows Server 2000 Viele Grüße olc

Hi gw5, mit findstr kannst Du ansatzweise "regular expressions" nutzen, vielleicht reicht Dir ja schon die "/b" Option: Findstr Ansonsten schau Dir die regexp-Optionen im Artikel an: DSGET.exe ist standardmäßig nur auf DCs installiert - aber wir wußten oben ja noch nicht, ob es client-seitig ausgeführt werden soll oder nicht. :) Schau Dir noch einmal Win32_TokenGroups an, das kann Dir auch weiterhelfen. Aber um das ganze noch einmal genauer zu beleuchten und zu prüfen, ob es nicht vielleicht auch andere Varianten geben würde: Was genau möchtest Du mit der Gruppenprüfung erreichen? Was ist Ziel der Aktion? Filterungen kannst Du etwa mit den GPP viel einfacher lösen als mit Loginscripts o.ä. Viele Grüße olc

Hi, wie Nils schon sagte ist das Maximum laut Schema nicht auf 20 Zeichen beschränkt (siehe das "Range-Upper" im verlinkten MSDN Artikel) - jedoch gibt es diverse Applikationen und/oder Dienste, die mit längeren sAMAccountName Attributwerten nicht umgehen können. Bei 16-20 Zeichen ist meist Schluß. AFAIR sind auch Microsoft Applikationen betroffen, vielleicht ist also "net.exe" ein Beispiel dafür. Wofür benötigst Du die Ausgabe genau? Wird sie im Benutzerkontext ausgegeben oder war das %username% nur ein Platzhalter für den Post hier? Alternativen wären neben vielen anderen Varianten zum Beispiel "whoami.exe /groups", "dsget user -memberof -expand" oder Win32_TokenGroups, je nach Anwendungszweck. Viele Grüße olc

Hi sky, schau einmal, ob Du über das GPP Logging etwas herausfinden kannst: Enabling Group Policy Preferences Debug Logging using the RSAT - Ask the Directory Services Team - Site Home - TechNet Blogs Viele Grüße olc

Hi, Wenn die GPP Dein Problem sind - dann "ja, das ist Dein Problem". Ist ja im Blog Eintrag recht nachvollziehbar beschrieben oder...? ;) Die Antwort hättest Du schon am 22.06.2011 haben können, wenn Deine Problembeschreibung genauer gewesen wäre. ;) Viele Grüße olc

Hi, neben dem Hinweis von blub könntest Du den DC auch in eine eigene Site verschieben und die "globalen" Einträge des DCs entfernen (und diese auch nicht neu schreiben lassen). Siehe dazu DnsAvoidRegisterRecords: How to optimize the location of a domain controller or global catalog that resides outside of a client's site Viele Grüße olc

Hi kirus22, erst ab Windows Server 2008 R2 Standard Edition sind die Zertifikatvorlagen in Version 2 oder 3 dabei. In Windows Server 2008 (ohne R2) war dieses Feature noch eine Zugabe der Enterprise Version / SKU. Siehe dazu auch: Active Directory Certificate Services Step-by-Step Guide D.h. auf dem Windows Server 2008 Standard bekommst Du keine V2 Templates. Du müßtest auf eine Enterprise Version wechseln oder gleich zu 2008 R2. Der Wiederherstellungsagent ist übrigens in beiden Betriebssystemen nur in der Enterprise Version enthalten, wenn ich mich nicht irre. Viele Grüße olc

Hi Daniel, zuerst mußt Du zwischen DNS und DFSN Auflösung unterscheiden: Bei der DNS Auflösung bekommt der Client einen Verweis auf einen DC in seiner Site. Ist dies schon nicht der Fall, stimmt wahrscheinlich etwas an Deiner DNS oder Site-Struktur nicht. Vermutlich hat der Client bei der Einwahl per VPN keine IP-Adresse, die einem Subnetz Deiner internen Struktur entspricht. Somit kann kein "site-lokaler" DC gefunden werden. Nachdem der DC per DNS lokalisiert wurde (unter Umständen schon der "falsche"), fragt der Client nun über den Workstation Service bei einem DC nach einem DFSN Referral. Da hier ebenso die Site-Zuordnungen nicht korrekt sein werden, kann auch hier kein DC der eigenen Site gefunden werden. Daher landest Du immer "auf irgend einem" DFSN Ziel. Ergo: Du mußt Dir überlegen, ob Du die Client-Subnetze auch bei Roadwarrior Einwahl in einem bestimmten, vordefinierten IP-Adressbereich gewährleisten kannst. Falls nicht, könnte man schauen, ob es andere Alternativen gibt. Falls der Client (das geht aus Deiner Erläuterung für mich nicht einwandfrei hervor) doch mit dem Subnetz der Site 1 in das "interne Netz" kommt, sollte der vom DNS zurückgegebene DC ein DC der Site 1 sein. Ist dies nicht der Fall, sind wir wieder bei einem Site Problem. Sollte der Client per DNS den korrekten DC bekommen (anhand Deiner Beschreibung sieht es nicht so aus), wären wir wieder bei DFSN. Hier könnte ein "repadmin /siteoptions DEIN_DC /site:SITE1 +W2K3_BRIDGES_REQUIRED " helfen, aber an dem Punkt sind wir noch nicht... Viele Grüße olc