daabm

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

Aber is schon geil, die Farbe. Noch nie gesehen, daß ein Auto im strahlenden Sonnenschein so konturlos werden kann 👍

Was sollte der NTLM-Response Dialekt des DC mit dem Zugriff auf ein anderes System zu tun haben - außer nichts natürlich Bin bei Zahni. Hatten die Netapp-Kollegen bei uns auch schwer damit zu tun.

Wir kämfpen seit 2 Jahren gegen NTLM.... Man kommt sich vor wie der junge Don Qujchotte... Und ich hab viel gelernt über Realms, Disjoint Namespaces und lauter so Zeug, was in einem nativen reinen Windows-AD-Umfeld einfach "out of the box" funktioniert. Aber natürlich stehen unsere Computer in DNS-Zonen, die keine Domain dahinter haben, registrieren aber die AD-Domains als SPN - und so geht das weiter. Drittanbieter scheitern gern komplett, weil sie mit Uni-(PAM-) Trusts nicht klarkommen und von "AuthUsers read all everywhere" ausgehen. Und natürlich keine Möglichkeit vorsehen, Realms zu definieren. Da läuft noch ganz viel Wasser irgendwelche Bäche runter.

Du könntest auf dem TS mal mit secpol.msc schauen, ob auch da ein Inaktivitätslimit gesetzt ist. Und natürlich auch alle anderen Policies bzgl. RDS Session Host und Session Limits prüfen.

Man muß es aber nicht auch noch promoten - das liest dann wieder jemand, bei dem Kerberos eigentlich völlig ok wäre und schwupps ist er downlevel... Und ja, man kann auch in Cert-SANs IP-Adressen verbuddeln, aber das wird jetzt [OT/]

Oha, da weiß noch jemand, daß man bei Infofenstern Strg-C drücken kann 👍

Erwähn das bitte nicht mehr. Wir wollen kein NTLM mehr...

Bin bei Norbert: nla durchstarten hilft. Geht notfalls per geplantem Task mit Trigger auf noch zu ermittelnde Events (gibt Eventlogs für wired und wifi, sollte sich was finden lassen).

In der Tat, wir sind gespannt. Sogar ich, obwohl ich mit XCH/EXO kaum zu tun habe Dafür kenne ich mich mit Schemas gut aus. Den Trainer würde ich gern mal kennen lernen. Und wenn die Lösung ist, das LDIF des Schemaupdates vorher zu manipulieren und alle Änderungen an User-Objekten rauszuwerfen: Viel Spaß, wenn dann mal ein Supportcase passiert...

Die RDP-Sitzung wurde "getrennt" oder "gesperrt"?