Alle Aktivitäten

Moin, also, wenn wir bei Vorträgen sind - vor langer Zeit habe ich mal einen Vortrag zu JEA gehalten, der ziemlich genau die oben genannten Anforderungen abdeckte. Ich weiß nicht mehr, ob der aufgezeichnet worden ist; es war auf einer der "CLoud & Datacenter"-Konferenzen. Und ich würde behaupten, dass das Beispiel auch in dem Rheinwerk-Buch behandelt wird ... ... ja, wird es, und zwar in Kapitel 3.7.8 - das habe ich seinerzeit geschrieben. Also, wenn es wirklich nur diese Anforderungen sind, dann kann das eine Alternative zu einem kommerziellen Tool sein. Gruß, Nils

Moin, hast Du eine bestimmte Anleitung befolgt? (nur damit wir nicht jeden Schritt einzeln abfragen müssen...)

@MurdocX übrigens ist der Test "auf \\domain.name als PU-Member zugreifen" kein guter, der wird immer scheitern, denn es ist ja nicht möglich, den von Dir zitierten SPN auf mehr als einem DC zu registrieren. Wir hatten vor ein paar Monaten einen Thread dazu, den ich gerade nicht finde. \\domain.name\SYSVOL ist kein Thema, denn dann ist der DFS-N-Zauber erledigt und die Verbindung geht auf \\einer-der-dcs.domain.name\SYSVOL, wo der SPN dann existiert. Explorer-Zugriff auf \\domain.name ist nur mit NTLM möglich - es sei denn, die Domäne hat nur einen DC, auf dem man dann den SPN cifs/domain.name zusätzlich registriert - dann geht auch Kerberos.

Ist jetzt zumindest seitens MS bestätigt und gefixed bzw. muss es evtl. per KIR gefixed werden: Windows 10, version 22H2 known issues and notifications | Microsoft Learn

Danke für alle Antworten bisher. NilsK, die Scripte schaue ich mir an. Deinen Vortrag habe ich mir nun gegeben. Du verweist am Ende auf dein Projekt-Repo, das die Zeit bis heute wohl nicht überlebt hat. Ist es obsolet geworden oder gab es andere Gründe, es zu löschen/migrieren? Carsten Rachfahl hat hier gezeigt, wozu er den 5nine Manager einsetzt, das Tool kann eine ganze Menge: https://www.hyper-v-server.de/management/5nine-manager-zur-administration-von-hyper-v/ Leider beschreibt er nicht, ob 5nine unsere Anforderung auch abbildet. Ich werde ihn am besten diesbzgl. kontaktieren und konkret nachfragen. MfG dw

I spoke too soon :-( Bei systematischem Testen, auf 2022, konnte ich die Situation nicht herbeiführen, dass sich ein User aus BRAVO, der dort in Protected Users ist, nicht in ALPHA interaktiv anmelden oder auf dortige Fileserver über SMB zugreifen könnte. Funktioniert alles einwandfrei. Meine Ideen waren: in dem Lab ist standardmäßig die Windows-Firewall auf "aktiv, aber offen" gesetzt --> das Rückführen auf Default-Regeln hat keine Änderung bewirkt in dem Lab ist (aus Performance- und Mimikatz-Gründen) Defender deaktiviert --> das Aktivieren inkl. Runtime-Protection hat keine Änderung gebracht alle VMs sind mit der gleichen unattend.inf gesysprepped, somit ist das Admin-Passwort bei allen gleich --> das Ändern des Admin-Passworts in allen Domänen und auf allen Members auf jeweils unterschiedliche Werte hat keine Änderung gebracht auf allen DCs war das DSRM-Kennwort ursprünglich identisch gesetzt (das schien die Bombe zu sein) --> das Ändern auf jeweils unterschiedliche Werte inkl. Reboot, Ticket Purge, Reboot hat keine Änderung gebracht Jetzt bleibt (euch) tatsächlich nur Loggen und Sniffen, denn ich kann's nach bestem Bemühen NICHT nachstellen.

Moin, zu der Scripting-Aufgabe für die Übersicht werfe ich mal mein seit vielen Jahren fertiges Script in den Ring. [Get-HyperVInventory: New Download Source is Here | faq-o-matic.net] https://www.faq-o-matic.net/2020/12/23/get-hypervinventory-new-download-source-is-here/ Gruß, Nils

Hallo, wir bauen grade unsere neue RDS Struktur auf ... SSO auf den Webaccess funktioniert ohne Probleme (ohne Login im Webaccess, RDP Verbindung ohne Eingabe von Credentials). Was jedoch nicht funktioniert ist die Einbindung in der Systemsteuerung unter RemoteAPPs , dort bekomme ich immer die Meldung "Benutzername und Kennwort falsch" und der Credentials Screen kommt. Dort kann ich mich mit den User Credentials anmelden und die RemoteAPPs werden angezeigt. Aber wie bekomme ich diesen Fehler noch weg? Habe schon einiges gelesen und versucht aber bisher keine Lösung finden können Client Windows 11, Server (Broker, Web, Lizenz) Server 2025

Super, danke für die schnelle Antwort. Da ja nach dem Update die alte Datenbank nicht mehr benötigt bzw. aktiv verwendet wird sollte das in dem Fall nicht so problematisch sein. Es wird, wie ich es verstanden habe, nur während der Migration zusätzliche DBs geben, danach sollte das wieder so laufen wie bisher.

Acronis hat bei 5nine zugeschlagen. Es scheint da jetzt nur noch den "Acronis Cloud Manager" zu geben. Da scheint dann aber wiederum ein "RBAC" mit drin zu sein.

Moin, es ist pro Datenbank. Allerdings ist es nicht die einzige Limitierung. Je nachdem, was in den Datenbanken so passiert, kann auch das Limit von 1 Socket (oder 4 Cores) einschränkend werden. Der Buffer Pool von 1,5 MB ist auch nicht riesig. Editions and Supported Features of SQL Server 2022 - SQL Server | Microsoft Learn

Ich meine, 5nine wurde in irgendwas hineingekauft.

Hallo zusammen, ich habe da eine vielleicht etwas doofe Frage bezüglich des Datenbanklimits bei SQL Express. Der hat ja ein Limit von 10GB für die Datenbank. Gilt das für alle Datenbanken auf diesem Server zusammen oder für jede einzeln? Hintergrund ist, dass ein Dienstleister für seine Software Anfang des Jahres einen SQL 2022 Express mit installiert hat (der Server macht nur diese Software und dessen Datenbank). Nun steht ein Update der Software an und der Support meint, es wäre besser einen neuen Server bereitzustellen, weil die brauchen ja auf jeden Fall eine zweite Datenbank dafür und dann käme man an das Limit ran, wenn die aktuelle mehr als 4 GB hat. Ich bin mir jetzt halt nicht sicher, ob das nicht nur Gequatsche von denen ist, weil die mehr Stunden verkaufen wollen (bin nicht wirklich überzeugt von deren Kompetenz, aber habe keine andere Wahl), oder ob das wirklich so ist. Aktuell haben alle Datenbanken zusammen ca. 6 GB, Wenn das Limit für alle gilt wäre das in der Tat etwas knapp, bei jeder einzelnen mache ich mir da keine Gedanken (die größte von den DBs hat knapp 4 GB aktuell.) Danke schon mal im Voraus für eure Antworten.

Moin zusammen, ich glaube, ich habe die Antwort, und sie wird euch - und uns alle - nicht erfreuen. Muss noch abschließend validieren. Aber der erste "dumme" Test mit 2019 war bei mir auch erfolgreich, somit ist es nicht versionsabhängig. Hang on, die Bombe kommt.

Hi, der 5nine Manager kann/konnte das AFAIK. Ist jetzt allerdings von Acronis und seit dem habe ich davon nichts mehr gehört. Alternativ JEA (Overview of Just Enough Administration (JEA) - PowerShell | Microsoft Learn). Das wird vermutlich auch im oben verlinkten Video behandelt. ;) Gruß Jan

Moin, ich habe darüber 2023 einen Vortrag auf der PSConfEU gehalten: https://youtu.be/-aZ2FJL7C5c Seitdem hat Microsoft so ein bisschen das WAC versaut, aber man kann das auch auf dem heutigen Stand stricken.

Hallo, wir betreiben einen Hyper-V-Cluster auf Server 2022 mit 4 Servern und möchten Kolle(inn)en die Möglichkeit geben, sich u.a. um folgende Themen zu kümmern: - eine Übersicht über alle VMs erstellen (VM-Name, Status, IP, VLAN) - VMs eingeschränkt verwalten (Shutdown, Start, Reboot, Snapshots erstellen/löschen/anwenden) Den ersten Punkt kann man evtl. scripten, für Punkt 2 finde ich nur die Gruppe der Hyper-V-Admins, die aber zu viele Rechte besitzen für das, was unsere Kollegen können müssen. Gibt es neben dem System Center Virtual Machine Manager Drittanbieter-Tools, über die diese granulare Aufgabenvergabe realisierbar ist? SCVMM ist dafür viel zu mächtig und vor allem zu teuer. Danke vorab. MfG dw

An mir soll es nicht scheitern Vollkommen richtig :/ # Versuch 1 Wie vorgeschlagen habe ich einen DA erstellt und ihn in die Protected Users geschmissen. Am DC angemeldet. Nun bekomme ich eine Fehlermeldung. DC-MUC-ROOT -> "\\berlin.local" (identisch mit dem anderen DC) # Versuch 2 Folgenden Fehler kann ich im Eventlog triggern, wenn ich mich mit DA + Protected-Users versuche vom MUC-DC zum BER-DC "\\berlin.local" auf die Share zu verbinden: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> - <System> <Provider Name="Microsoft-Windows-Security-Kerberos" Guid="{98e6cfcb-ee0a-41e0-a57b-622d4e1b30b1}" /> <EventID>100</EventID> <Version>0</Version> <Level>2</Level> <Task>0</Task> <Opcode>0</Opcode> <Keywords>0x8000000000000000</Keywords> <TimeCreated SystemTime="2025-11-03T22:24:02.4441868Z" /> <EventRecordID>181</EventRecordID> <Correlation /> <Execution ProcessID="884" ThreadID="4012" /> <Channel>Microsoft-Windows-Kerberos/Operational</Channel> <Computer>DC-MUC-ROOT.muenchen.local</Computer> <Security UserID="S-1-5-18" /> </System> - <EventData> <Data Name="SPN">cifs/berlin.local@BERLIN.LOCAL</Data> <Data Name="ErrorCode">7</Data> </EventData> </Event> # Abfrage registrierter SPNs auf dem DC-BER-ROOT PS C:\Users\Administrator> setspn.exe -L DC-BER-ROOT Registered ServicePrincipalNames for CN=DC-BER-ROOT,OU=Domain Controllers,DC=berlin,DC=local: Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/DC-BER-ROOT.berlin.local ldap/DC-BER-ROOT.berlin.local/ForestDnsZones.berlin.local ldap/DC-BER-ROOT.berlin.local/DomainDnsZones.berlin.local TERMSRV/DC-BER-ROOT TERMSRV/DC-BER-ROOT.berlin.local DNS/DC-BER-ROOT.berlin.local GC/DC-BER-ROOT.berlin.local/berlin.local RestrictedKrbHost/DC-BER-ROOT.berlin.local RestrictedKrbHost/DC-BER-ROOT RPC/48f0492e-6c55-4aa3-a3d2-7ed973937035._msdcs.berlin.local HOST/DC-BER-ROOT/BERLIN HOST/DC-BER-ROOT.berlin.local/BERLIN HOST/DC-BER-ROOT HOST/DC-BER-ROOT.berlin.local HOST/DC-BER-ROOT.berlin.local/berlin.local E3514235-4B06-11D1-AB04-00C04FC2DCD2/48f0492e-6c55-4aa3-a3d2-7ed973937035/berlin.local ldap/DC-BER-ROOT/BERLIN ldap/48f0492e-6c55-4aa3-a3d2-7ed973937035._msdcs.berlin.local ldap/DC-BER-ROOT.berlin.local/BERLIN ldap/DC-BER-ROOT ldap/DC-BER-ROOT.berlin.local ldap/DC-BER-ROOT.berlin.local/berlin.local

Ich habe Mittwoch bis Freitag Seminar. Wie cool wäre es, wenn wir es gelöst kriegen und ich live darüber erzählen kann Aber ich schau mal, ob ich morgen ein 2019er Lab schnell hingeworfen kriege. Aber ohne FAST!! Und bei mir ist auch dieses Ticket mit FAST. OK, also wir haben: @mzahneissen 2019 --> funktioniert nur mit Supported @cj_berlin 2022 --> funktioniert mit Enforced @MurdocX 2025 --> funktioniert nur mit Supported Bei 2025 glaube ich inzwischen alles, aber 2019 ist eigentlich gut abgehangen und sollte auf 2022er Niveau funktionieren...

Die Client-Policy ist auf dem Domänen-Ebene gesetzt und wurde auch übernommen, laut gpresult. Ich setze für den Test auf Server-2025. -> "protected users" bin ich gerade noch am testen, weil ich mich ja über kerberos verbinden muss Jetzt könnte es interessant werden. Ich sehe genau die Tickets auf die du aufmerksam gemacht hast. # Konfiguration ⚙️ KDC - Kerberos Amoring -> "Supported" # DC-MUC-ROOT PS C:\Users\Administrator> klist -li 0x3e7 Current LogonId is 0:0x1426900 Targeted LogonId is 0:0x3e7 Cached Tickets: (5) #0> Client: dc-muc-root$ @ MUENCHEN.LOCAL Server: krbtgt/BERLIN.LOCAL @ BERLIN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize Start Time: 11/3/2025 13:27:47 (local) End Time: 11/3/2025 23:25:26 (local) Renew Time: 11/10/2025 13:25:26 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x200 -> DISABLE-TGT-DELEGATION Kdc Called: DC-BER-ROOT.berlin.local #1> Client: dc-muc-root$ @ MUENCHEN.LOCAL Server: krbtgt/BERLIN.LOCAL @ MUENCHEN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize Start Time: 11/3/2025 13:27:47 (local) End Time: 11/3/2025 23:25:26 (local) Renew Time: 11/10/2025 13:25:26 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x240 -> FAST DISABLE-TGT-DELEGATION Kdc Called: DC-MUC-ROOT #2> Client: dc-muc-root$ @ MUENCHEN.LOCAL Server: krbtgt/MUENCHEN.LOCAL @ MUENCHEN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize Start Time: 11/3/2025 13:25:26 (local) End Time: 11/3/2025 23:25:26 (local) Renew Time: 11/10/2025 13:25:26 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x1 -> PRIMARY Kdc Called: DC-MUC-ROOT #3> Client: dc-muc-root$ @ MUENCHEN.LOCAL Server: LDAP/DC-MUC-ROOT.muenchen.local/muenchen.local @ MUENCHEN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize Start Time: 11/3/2025 13:25:57 (local) End Time: 11/3/2025 23:25:26 (local) Renew Time: 11/10/2025 13:25:26 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-MUC-ROOT #4> Client: dc-muc-root$ @ MUENCHEN.LOCAL Server: ldap/DC-MUC-ROOT.muenchen.local @ MUENCHEN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize Start Time: 11/3/2025 13:25:26 (local) End Time: 11/3/2025 23:25:26 (local) Renew Time: 11/10/2025 13:25:26 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-MUC-ROOT # DC-BER-ROOT PS C:\Users\Administrator> klist -li 0x3e7 Current LogonId is 0:0x4c6bc Targeted LogonId is 0:0x3e7 Cached Tickets: (9) #0> Client: dc-ber-root$ @ BERLIN.LOCAL Server: krbtgt/BERLIN.LOCAL @ BERLIN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x60a10000 -> forwardable forwarded renewable pre_authent name_canonicalize Start Time: 11/3/2025 13:29:14 (local) End Time: 11/3/2025 23:25:25 (local) Renew Time: 11/10/2025 13:25:25 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x42 -> DELEGATION FAST Kdc Called: DC-BER-ROOT #1> Client: dc-ber-root$ @ BERLIN.LOCAL Server: krbtgt/MUENCHEN.LOCAL @ MUENCHEN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize Start Time: 11/3/2025 13:27:56 (local) End Time: 11/3/2025 23:25:25 (local) Renew Time: 11/10/2025 13:25:25 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x200 -> DISABLE-TGT-DELEGATION Kdc Called: DC-MUC-ROOT.muenchen.local #2> Client: dc-ber-root$ @ BERLIN.LOCAL Server: krbtgt/MUENCHEN.LOCAL @ BERLIN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize Start Time: 11/3/2025 13:27:56 (local) End Time: 11/3/2025 23:25:25 (local) Renew Time: 11/10/2025 13:25:25 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x240 -> FAST DISABLE-TGT-DELEGATION Kdc Called: DC-BER-ROOT #3> Client: dc-ber-root$ @ BERLIN.LOCAL Server: krbtgt/BERLIN.LOCAL @ BERLIN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize Start Time: 11/3/2025 13:25:25 (local) End Time: 11/3/2025 23:25:25 (local) Renew Time: 11/10/2025 13:25:25 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x1 -> PRIMARY Kdc Called: DC-BER-ROOT #4> Client: dc-ber-root$ @ BERLIN.LOCAL Server: cifs/DC-BER-ROOT @ BERLIN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize Start Time: 11/3/2025 13:29:58 (local) End Time: 11/3/2025 23:25:25 (local) Renew Time: 11/10/2025 13:25:25 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-BER-ROOT #5> Client: dc-ber-root$ @ BERLIN.LOCAL Server: DC-BER-ROOT$ @ BERLIN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize Start Time: 11/3/2025 13:29:14 (local) End Time: 11/3/2025 23:25:25 (local) Renew Time: 11/10/2025 13:25:25 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-BER-ROOT #6> Client: dc-ber-root$ @ BERLIN.LOCAL Server: cifs/DC-BER-ROOT.berlin.local/berlin.local @ BERLIN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize Start Time: 11/3/2025 13:29:14 (local) End Time: 11/3/2025 23:25:25 (local) Renew Time: 11/10/2025 13:25:25 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-BER-ROOT #7> Client: dc-ber-root$ @ BERLIN.LOCAL Server: ldap/DC-BER-ROOT.berlin.local/berlin.local @ BERLIN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize Start Time: 11/3/2025 13:29:14 (local) End Time: 11/3/2025 23:25:25 (local) Renew Time: 11/10/2025 13:25:25 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-BER-ROOT #8> Client: dc-ber-root$ @ BERLIN.LOCAL Server: ldap/DC-BER-ROOT.berlin.local @ BERLIN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize Start Time: 11/3/2025 13:25:25 (local) End Time: 11/3/2025 23:25:25 (local) Renew Time: 11/10/2025 13:25:25 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-BER-ROOT

richtig, bei mir sind alle DCs 2019, DFL und FFL 2016. Trust-Konfig und Klist kann ich erst Mittwoch bei mir vergleichen.

Trust-Einstellungen sind bei mir genau so, es muss auch nichts am Trust extra fürs Armoring gesetzt werden - außer, dass die Client-Policy auch auf DCs gelten muss, aber ich schätze, das ist der Fall, denn sonst würde man sich gar nicht mehr anmelden können. Spannend. Ist es vielleicht doch ein OS-Versionsthema? Ich meine, einer von euch erwähnte 2019er DCs? Schon zu spät, um den Thread nochmal aufmerksam zu lesen...

@cj_berlin Danke für deine Vorschläge. Ich setze die Konfig gleich um und poste. Müssen beim Trust noch Konfigurationen für Claims/Amoring gesetzt werden? Um hier eventuell ein Problem mit dem Trust auf die Schliche zu kommen, habe ich die Konfiguration ausgelesen. # DC-BER-ROOT PS C:\Users\Administrator> Get-ADTrust -Identity "muenchen.local" Direction : BiDirectional DisallowTransivity : False DistinguishedName : CN=muenchen.local,CN=System,DC=berlin,DC=local ForestTransitive : True IntraForest : False IsTreeParent : False IsTreeRoot : False Name : muenchen.local ObjectClass : trustedDomain ObjectGUID : 3e9bfdd5-73ab-49f1-bb6b-438038670354 SelectiveAuthentication : False SIDFilteringForestAware : False SIDFilteringQuarantined : False Source : DC=berlin,DC=local Target : muenchen.local TGTDelegation : False TrustAttributes : 8 TrustedPolicy : TrustingPolicy : TrustType : Uplevel UplevelOnly : False UsesAESKeys : False UsesRC4Encryption : False # DC-MUC-ROOT PS C:\Users\Administrator> Get-ADTrust -Identity "berlin.local" Direction : BiDirectional DisallowTransivity : False DistinguishedName : CN=berlin.local,CN=System,DC=muenchen,DC=local ForestTransitive : True IntraForest : False IsTreeParent : False IsTreeRoot : False Name : berlin.local ObjectClass : trustedDomain ObjectGUID : 9ac50009-8284-4ef3-908b-d8d481c6a742 SelectiveAuthentication : False SIDFilteringForestAware : False SIDFilteringQuarantined : False Source : DC=muenchen,DC=local Target : berlin.local TGTDelegation : False TrustAttributes : 8 TrustedPolicy : TrustingPolicy : TrustType : Uplevel UplevelOnly : False UsesAESKeys : False UsesRC4Encryption : False

Hmm, es fehlt das krbtgt-ST von der Gegenseite, durch diese bestätigt. Du hast: aber nicht (eingerahmt ist mein Äquivalent zu dem o.g. Ticket #0). Somit findet tratsächlich kein Kerberos über den Trust statt. Jetzt wäre spannend, ob dieses Ticket erscheint, wenn Armoring auf "Supported" steht... Falls ja, ist es, glaube ich, ein Fall für Wireshark und sehr hoch aufgedrehtes Diagnostic Logging... ...und wenn das Ticket nicht erscheint und der Zugriff dennoch zu funktionieren scheint - versucht's mal mit einem User, der in "Protected Users" Mitglied ist Nicht, dass doch ein Fallback auf NTLM stattfindet...