daabm

Kurzer Nachtrag dazu: Wenn der LDAP-Filter zu groß wird, geht das in die Hose. Nach ein paar Tests mit sAMAccountName - sind es mehr als ~40k Einträge (der Filter ist dann etwa 1 MB groß), verweigert der Server die Antwort. Belastbare Informationen über entsprechende Limits habe ich aber keine gefunden... Wenn jemand was dazu hat, gerne her damit $LDAPFilter = "(|" + ( ( 1..50000 | Foreach { "(sAMAccountName=User$_)" } ) -join '' ) + ")" $LDAPFilter.Length ( Measure-Command { $ADobjects = Get-ADObject -LDAPFilter $LDAPFilter } ).TotalSeconds Ergebnis: 1158897 Get-ADObject : Es kann keine Verbindung mit dem Server hergestellt werden. Dies liegt möglicherweise daran, dass der Server nicht vorhanden oder derzeit ausgefallen ist oder dass darauf nicht Active Directory-Webdienste ausgeführt wird. In Zeile:3 Zeichen:34 + ... e-Command { $ADobjects = Get-ADObject -LDAPFilter $LDAPFilter } ).Tot ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ResourceUnavailable: (:) [Get-ADObject], ADServerDownException + FullyQualifiedErrorId : ActiveDirectoryServer:0,Microsoft.ActiveDirectory.Management.Commands.GetADObject 0,319832

...aber reiß dabei nicht dem, der sie dir entgegenstreckt, den Arm aus. SCNR

Das hängt ganz sicher (hust...) nicht zusammen.

Bitte nicht zu viel durcheinander werfen NTLM bekommst Du in den Griff, wenn Du auf den DCs das NLTM Auditing einschaltest. Dann kannst Du im Eventlog NTLM/Operational nachschauen, von wo das kommt. Und damit kannst Du dann analysieren, warum Kerberos nicht funktioniert. Dazu wiederum ist es hilfreich, auf den DCs das Advanced Auditing für Kerberos-Events zu aktivieren und die dann auf Audit Failure Events zu prüfen. Das Event mit der Server-Referenz habe ich noch nie gesehen... Da bin ich also erst mal raus und stille.

Danke für die Rückmeldung. Kommt bei uns quasi quartalsweise vor (>1000 Domains....), Ursache unbekannt. Aber man gewöhnt sich dran, und es ist schnell und einfach zu beheben.

Ganz viel skripten. Also alles eigentlich. Und alles, was mehr als ein Objekt bearbeitet, auf Performance optimieren...

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...