daabm

Toll was Du alles hast. Und was trägt das zur Ursprungsfrage bei?

So ne moderne Cloud-Lösung? SCNR - duck und weg...

Sollte verschwinden, wenn die AD-Replikation a) funktioniert b) abgeschlossen ist c) alle Client/User-TGTs erneuert sind

klist erzählt Dir schon mal, welche Tickets du hast. Hat der RDS keine SPNs mehr registriert? klist get TERMSRV/<FQDNdesRDS> Und so weiter BTW - "IPs getauscht", bist Du sicher, daß alle DNS-SRV-Records sauber sind? nslookup -type=ALL _kerberos._tcp.<DomainFQDN> liefert was genau? (Spoiler: "ALL" muss hier großgeschrieben werden...)

Ich glaub das geht alles am Fehler vorbei... Ohne mehr Infos wird das IMHO nichts. ERROR_CANT_ACCESS_FILE ist doch kein ACL-Problem?!? Und ne Freigabe muß ja da sein, sonst käme man schon gar nicht soweit. Gibt's evtl. auch noch DFS dazu?

Recommended. GPOs immer auf dem System bearbeiten, auf das man damit zielt. Macht vieles einfacher. Vor allem bei den Security Settings, die nicht aus Templates kommen, sondern aus der (lokalen!) scecli.dll...

To add some more: Bowmore 12/15/18 (wußte gar nicht, daß es 17 auch gibt), Laphroigh 10/15/Cask - wenn ich letzteren nur die Flasche aufmache, verlassen empfindliche Gemüter bereits den Raum

Ok, das paßt dann auch besser zu meiner Erinnerung Danke.

Ne muß rein. Sonst meckert die Frau (die bei Dir ja nicht meckern kann), daß Du nicht so viel Rum trinken sollst. So ist es dann einfacher - "ist doch nur ein Eiergrog" 😂

10 cl Rum unter einem Alibi-Häubchen Eigelb?

Dann hätte ich mal besser die Klappe gehalten - wir haben uns das auf DCs nie angeschaut, weil da die Notfallkonten schon immer (anders) verwaltet waren.

Wart mal bis Sonntag... Je nach Familienstand werden Dir Mutter/Freundin/Frau/Kinder schon erklären, warum da jetzt ein Licht aufgeht.

LAPS ist für Member Server schon ok. Naja, "brauchbar". Für DCs definitiv natürlich nicht, und für den DSRM-Admin auch nicht. Der ist ja für LAPS nicht sichtbar, da in der alten lokalen SAM der DCs (bzw. also deren Registry) verbuddelt. Lösung bei uns: Zentrale PW-Verwaltung (CyberArk). Die bringt dann auch gleich Checkout/Checkin/Reconcile und noch so ein paar Dinge mit, die bei LAPS alle fehlen. Was aber alles mit Protected Users nichts zu tun hat

Ojeh. Und "keine Lösung" ist jetzt ernsthaft "ja es gibt eine Lösung"???

Hab ich genug. Ansonsten Elektroauto... "Querschnitt der Rotorwicklungen"?

Advent, Advent kann kommen 🕯️

Es reicht schon, einer NW-Karte eine verbindungslokale IPv6 zu verpassen - auch das triggert NLA. Und ja, der Mechanismus hat deutlich "Luft nach oben" - vor allem wenn man im öffentlichen Profil Outbound blockt und nur zulässt, was zur DC-Etkenneung "angeblich" erforderlich ist. Und nein, was man dazu im Netz findet, reicht nicht.

"Was ist ein Treiber?" SCNR...

Hier mußt Du dafür auf den nächsten Hügel krabbeln - alles "rauf runter rauf runter", ständige Höhenunterschiede von 50 bis ~300 Meter.

Genau. Multi Domain kein Problem, wenn es ein Forest (mit GC ! ) ist. Haben wir aber nicht, wir haben 2 Forests. Und weil das als Virtual Appliance daherkommt, gibt es auch keinen Root-Zugriff und man kommt an die Eingeweide nicht ran.

"Am leichten Hang wohnen" soll auch helfen. Gibt halt Gegenden, wo es weit und breit keinen Hang gibt. Und wenn der zu steil wird, ist es auch wieder nix

Ja, kann man. Problem sind nicht die 2 Domänen, sondern daß es nur einen Bind-User in Domäne A geben soll, nicht in Domäne B. Bei den AD-Sources kann man aber nirgends angeben, wo sich der Bind-User befindet. Ok, in seinem DN steht es drin, aber wir vermuten, daß Clearpass den DN intern mit dem Hostnamen (=Zieldomäne) ergänzt, so daß LDAP://<DomäneB>:636/<BindDNausDomäneA> daraus wird. Innerhalb eines Forest und mit 3269 statt 636 würde das ja funktionieren, aber wir haben halt 2 Forests - der DN von Domäne A ist in Domäne B natürlich ungültig.

@Nobbyaushb Der DC möchte da DC sein. Ist hier auch so... Hatte keine Lust, die Windows-Domäne in eine SAMBA-Domäne zu migrieren, und die Synos können in einer Windows-Domäne kein DC werden. Also laufen die Windows-DC jetzt als VM auf den Synos, die in diese Domäne gejoint sind Muß man ein wenig tricksen bei AD-integriertem DNS, wenn Synology Updates für QEmu ausliefert - da waren mal beide DC nicht erreichbar, und die Synos müssen deshalb auch noch secondary DNS sein und sich selbst als DNS verwenden. Geht aber problemlos. Und selbstverständlich gibt es auch auf einem DC lokale Richtlinien - siehe secpol.msc. (Fast) alles, was nicht aus einer GPO kommt, ist lokal. Ausnahme nur PW-Policies, die aus dem Domain Head in die DDP zurückwandern.

Hallo zusammen. Hat eigentlich nichts mit Windows direkt zu tun, aber hier paßt es am besten rein... Ein Kunde setzt Aruba Clearpass als VPN-Lösung ein. User sind in Domäne A, Computer in Domäne B. Technischer Bind-User für Aruba ist auch in Domäne A. Die Domänen sind NICHT im gleichen Forest, aber es gibt einen Bidi-Trust. Die Clearpass-Appliance ist NICHT Mitglied einer dieser Domänen. Wie muß Clearpass konfiguriert werden, damit der Bind-User aus Domäne A in Domäne B authentifiziert werden kann? (Authentifizierung in Domäne A funktioniert problemlos.) Die Doku (https://www.arubanetworks.com/techdocs/ClearPass/6.7/Aruba_DeployGd_HTML/Default.htm#Active Directory/AD_auth_source_adding.htm%3FTocPath%3DPreparing%20ClearPass%20for%20Active%20Directory%20Authentication|_____2) hab ich gelesen, aber da finde ich keine Erhellung. Und der Multi-Domain Support von Clearpass scheint sich auf einen Forest zu beschränken, in dem dann nicht AD (389/636) gefragt wird, sondern GC (3268/3269). Bin für jeden Tip dankbar - der Kunde auch Gruß Martin