daabm

1. Wieso abtippen? 2. Das Kennwort, das DC04 in seiner AD-Datenbank für DC03 hat, ist nicht identisch mit dem, das DC03 hat (AD-Replikation in Ordnung?). Oder das krbtgt-Kennwort ist "out of sync". Erster Lösungsansatz: Dienst KDC auf allen DCs außer dem PDC-Emulator deaktivieren und stoppen (!!!), dann alle DCs neu starten außer dem PDC. Dann 10 Minuten warten und KDC auf allen DCs wieder aktivieren und starten. Zweiter Ansatz: DC03 SecureChannel zurücksetzen. Dritter Ansatz: DC03 neu aufbauen.

Ja, das ist supported. AD ist bei DNS völlig agnostisch, nur muß jeder Computer in der Lage sein, die erforderlichen Einträge zu registrieren (oder ein irgendwie gearteter Automat übernimmt das).

Hallo zusammen. Keine Frage, nur ein Tip, wenn's mal schneller gehen soll Wenn man in Active Directory User/Gruppen/Mitgliedschaften auslesen oder bearbeiten will, findet man oft Schleifen, die über Mitglieder oder Mitgliedschaften iterieren und mit den Ergebnissen dann wieder etwas machen. Das läßt sich dramatisch beschleunigen, indem man nicht iteriert, sondern vorher einen passenden LDAP-Filter baut. Und LDAP-Filter dürfen lang sein - sehr lang. Ich hatte das Thema kürzlich, als es um Account-Dubletten im Rahmen von Domänen-Migrationen ging. Das "übliche" Vorgehen wäre wohl, auf der einen Seite alle Accounts zu holen und dann für jeden Account zu prüfen, ob es den auch auf der anderen Seite gibt. Holt man die Accounts der anderen Seite dagegen über einen LDAP-Filter auf die Accounts, die man auf der ersten Seite schon gefunden hat (nur die können ja doppelt vorhanden sein), wird das dramatisch schneller... Getestet mit bis zu 2.000 sAMAccountName im LDAP-Filter, geht problemlos. Die einzige Herausforderung dabei ist, den Input (also das Member- oder MemberOf-Array) passend zu zerlegen. Ich habe mich für die einfachste Variante entschieden, und ich setze auch voraus, daß der CN eindeutig ist. Aber egal wie aufwändig das Konstruieren des LDAP-Filter wird - es wird immer um Größenordnungen schneller gehen als die Objekte einzeln zu holen. Sample Code - $GroupName muss natürlich angepasst werden, wenn das jemand ausprobieren will: $GroupName = 'LDAPFilterGroup' $Group = Get-ADGroup $GroupName -Properties Member $NumRepetitions = 5 $ScriptBlocks = @( { $Members = @() Foreach ( $Member in $Group.member ) { $Members += Get-ADObject $Member } }, { $Members = [Collections.Arraylist]::new() Foreach ( $Member in $Group.member ) { [void] $Members.Add( ( Get-ADObject $Member ) ) } }, { $GroupMembers = $Group.Member | Foreach { ( $_ -Split ',(OU|CN)=' -Replace '^CN=', '' )[0] } $LdapFilter = '(|(sAMAccountName=' + ( $GroupMembers -join ')(sAMAccountName=' ) + '))' $Members = Get-ADObject -LDAPFilter $LdapFilter } ) Foreach ( $ScriptBlock in $ScriptBlocks ) { $Durations = For ( $i=1; $i -le $NumRepetitions; $i++ ) { Measure-Command -Expression $ScriptBlock } $Durations | Measure-Object TotalSeconds -Average | Select-Object Average } Ergebnis in einer Spielumgebung für eine Gruppe mit 1.000 Mitgliedern in Sekunden: Foreach mit @(): 6,5145044 Foreach mit ArrayList: 5,96655574 LDAP-Filter: 0,75933482 Muß man glaub nix mehr dazu sagen... [Collections.Arraylist] spart schon bei nur 1.000 Accounts eine halbe Sekunde, aber Variante 3 mit dem "extrem langen LDAP-Filter" ist um den Faktor 10 schneller (der Filter hat knapp 24 kB). Und das wird immer schlimmer für die anderen beiden Methoden, wenn es mehr Mitglieder sind und die Netzwerkverbindung langsamer. Edit: Warum ich auf so was achte? Weil manche unserer Domains 150.000 User, 30.000 OUs und 10.000 GPOs haben. Die Anzahl der Gruppen weiß ich nicht, aber auch irgendwo im 6-stelligen Bereich. Da ist Geschwindigkeit alles...

Ernsthaft? Dann stimmt was im Preisgefüge "Produktion vs. Transport" aber gar nicht mehr...

"Geh mit mir Shoppen"?

Schwafelt blödes Zeug und gibt nichtssagende Antworten. BTT: Ich bin bei @cj_berlin - ein Nicht-Admin hat in diesem Menü nichts, womit er irgendwas anstellen kann, das irgendwelche Auswirkungen auf andere User oder den Computer hat. Also wozu? Aber wenn's Dich glücklich macht - erstell den relevanten AppData-Ordner per GPP Preferences und mach ihn Readonly/Hidden, dann sind alle Einträge weg bis auf Desktop. Behaupten manche - ich probier das nicht aus, weil ich ja das "wofür" nicht nachvollziehen kann

Im Zweifel hilft regedit - HKLM\System\CurrentControlSet\Services. Da kann sich kein Service wehren, wenn Du Dinge änderst

Vergiß den Assistenten. Freigaben und NTFS-ACLs macht man nicht über Assistenten.

Stimmt. Wir machen beides 😂

Nicht, wenn Du über 300 davon hast...

An den 2 Punkten scheitern wir. Den ersten hatten wir - aber jetzt liegen die PW der Builtin Admins in einem zentralen Store (Cyberark), der die auch rotiert. Und da wir dafür derzeit keinen Reconcile-Account aus der Domäne nutzen, muß Cyberark sich mit den aktuellen Credentials remote verbinden dürfen :-( (Nicht mein Design, ich kann die Welt nicht alleine retten). Den zweiten würden wir gern machen, geht aber nicht, weil wir zu viel Bewegung in unseren Netzen haben und zu viele Menschen für unterschiedliche Teile der RDP-Zugriffskette verantwortlich sind. Wobei ich die Idee mal mitnehme und mit ein paar Menschen besprechen werde, weil das eigentlich ein QuickWin wäre. Beim Rest Daumen weit hoch von mir. Für "nur" 100 MA hast Du da echt viel umgesetzt 👍 PS: Network Access haben wir auf AuthUsers belassen - das hätten wir nie eingefangen bekommen, wenn da per Default niemand drinsteht und jeder, der nen Service aufbauen will, sich darum auch noch kümmern darf...

Och menno - warum nicht? Ich würde doch so gerne... 🙈

Wenn ich mir meinen Aufmerksamkeitspegel in manchen Meetings so überlege, könnten da auch Schimpansen oder Pandas sitzen, würde ich nicht merken... 🙈

Dagegen hilft nur striktes Identity Management und Review aller "ungeklärten" Accounts, bis sie weg sind. Wir sind dran, aber das ist auch ein größerer Act... Vor allem, wenn sich die Accounts sporadisch noch anmelden, keine Beschreibung haben und die in der Description händisch eingetragenen Ansprechpartner seit 8 Jahren nicht mehr im Unternehmen sind 🙈 Das ist rechnung.zip.exe auf Steroiden... Echt krasse Show

Danke für die Aufklärung - man lernt nie aus... 👍

Ach halt doch die Klappe 😂 Um wieder auf was fachliches zurückzukommen: Alleine die Quirks, die uns Kerberos beschert hat, reichen für ein Buch. Disjoint Namespaces, DNS-Aliase ohne Ende (damit jeder "seinen" persönlichen Namen ansprechen kann), Accounts aus unterschiedlichsten AD-Domains, die auf DNS-Namen in "irgendwelchen" DNS-Domains zugreifen wollen - Du wirst nicht fertig. Bis jeder erst mal verstanden hat, daß ein FQDN hinten eben kein Realm hat, sondern nur nen DNS-Namensraum - da kriegst schon Junge. Und geschätzt 1/2 unserer FQDNs enden nicht auf Kerberos-Realms (=AD-Domains), sondern nur auf DNS. So viele Mappings kannst gar nicht machen... Und mit NTLM war das alles "gar kein Problem" 🙈

Seit wann ist e-Mail eine rechtlich zustellbare Kommunikationsmethode? DEMail wurde eingestellt, seither gibt's das für Privatpersonen nicht mehr. Du kannst keine "rechtlich zugestellte" Mail verschicken.

Ich könnte noch viel mehr erzählen. Ich mag Xavier eigentlich nicht (zu komische Ansichten), aber "dieser Weg wird kein leichter sein"... Sparkassenwerbung?

Ne, ich nehm die Fähnchen...

Aus dem Alltag eines Umsetzungsveranstalters... Einführung von Tier-Trennung und Eliminieren von NTLM-Auth: Du mußt jedem erst mal erklären, warum er jetzt ne Domain mit angeben muß. Du mußt danach jedem auch erklären, daß es überhaupt verschiedene Domains gibt und warum das wichtig ist. Danach erklärst Du dann den "Doppel-Tier-Leuten", warum sie jetzt 2 Accounts haben und mit denen jeweils andere Dinge können bzw. eben nicht können. Und warum das alles vom Arbeitsplatz aus gar nicht mehr geht. Damit hast Du die Basics der Tier-Trennung aus Sicht "Admin-Accounts" beinahe durch - wenn man ignoriert, daß "eigentlich" auch alle Peripheriesysteme (Identity Management, Systems Management, Inventory Scanner etc.) getrennt aufgebaut werden müssen. Das bezahlt aber quasi niemand, da wirst Du Kompromisse eingehen müssen. Das Thema PAW ist damit auch noch ungelöst - wir haben's mit CyberArk gemacht. MFA ebenso. Und gegen "verschlüsselt in der Ecke" hilft das auch nur bedingt. Im Kontext des Work-Accounts kann man halt immer alles verschlüsseln, auf das der Work-Account Schreibrechte hat. Wenn Du (wie wir) gleichzeitig versuchst, NTLM loszuwerden, mußt Du dann jedem erklären, warum sein Adminserver jetzt nicht nur seine Zielserver erreichen muß, sondern auch ziemlich viele DCs. Und warum DNS-Aliase nicht mehr funktionieren. Und warum er plötzlich nicht mehr auf \\10.0.1.15\c$ kommt... ("Ging doch bisher immer") Dann aktivierst Du LDAP Channel Binding und stellst fest, daß Deine Loadbalancer für LDAPS über Nacht unbrauchbar geworden sind, weil sie SSL terminieren. Und dann merkst Du, daß die meisten MFP (Scan to Folder) zwar Kerberos unterstützen, aber daran sterben, wenn der Serviceaccount nicht im Realm der Domain ist. Und daß auch ganz viele Drittanbieter Kerberos "unterstützen", aber nur wenn alles in einem Realm liegt. Daran stirbt übrigens sogar .NET - System.DirectoryServices.AccountManagement verträgt es nicht, wenn der ausführende Account aus einer trusted Domain kommt: https://github.com/dotnet/runtime/issues/95676. Und es stirbt auch, wenn GetAuthorizationGroups aufgerufen wird, der Zielaccount Mitglied von Gruppen ist, die ForeignSecurityPrincipals als weitere Mitglieder haben (warum das überhaupt geprüft wird, weiß nur MS) und der ausführende Account keine Leserechte auf die FSP-Objekte hat. Citrix PVS hat auch ganz lustige Probleme mit Trusts. Die checken nämlich an bestimmten Stellen nicht "reale" Gruppenmitgliedschaften von Serviceaccounts, sondern schauen ins AD. Konkret mußte ein Serviceaccount aus einer trusted Domain dort (!) in eine domain local (!) Group... 🙈 Wenn Du dann noch aufgrund "organisatorischer Anforderungen" (= Management-Wünsche) disjoint Namespaces hast, dann hast Du jetzt richtig Spaß an der Sache 😁 Und bist für mehrere Jahre unentbehrlich . Da fließt noch sehr viel Wasser ins Meer... PS: Wir haben ~8.000 MA im Konzern.

Möge uns der Pliot wohlbehalten ans Ziel bringen 😁

Niemand - bei Powershell gibt es zu viele Möglichkeiten für "stupid implementation". Und bei LDAP auch. Hab genug Kollegen, die immer noch - sinngemäß - so was machen: $Groups = Get-ADGroup -Filter * -Prop * | Foreach { Select Name } | Where Name -like "WasSucheIcheigentlich" Da kannst nix mit Effizienzvergleichen bezüglich der Sprache anfangen.

Ich fahre Auto oder Fahrrad. Wie fährt man 4K? SCNR... 😁

Ich weiß, daß es vor 2 Jahren noch verarbeitet wurde. Und ich weiß auch, daß das GP-Team bei Microsoft nicht mehr als Team bezeichnet werden kann, zu wenig Menschen. Da wird sich nichts geändert haben.

Korrektur... AFAIK: Man kann keine PW mehr eintragen im UI. Wenn sie aber drin sind, werden sie weiterhin verarbeitet. Und wenn dann keiner "call to action" ruft, ändert sich halt nix. MS hat damals leider versäumt, nicht nur das UI zu patchen, sondern auch die CSE.