phatair

Hi, leider nein Microsoft ist der Meinung, dass ihre Defender Lösung trotzdem noch teilweise laufen sollte... Ich finde es auch ziemlich unverständlich. Vor allem weil der Security Anbieter (MS Defender) im Security Center als deaktiviert deklariert wird. Ist er aber nicht, so lange man die SmartAppControl Funktion noch aktiviert hat. Das ist mal wieder MS Logik In der Enterprise Version ist die Funktion wohl ausgeschaltet. Wir nutzen aber Windows Pro in unserer Umgebung. Das meiste haben wir im Image gut angepasst bekommen, so dass der ganze Consumer Mist wegfällt. Aber jetzt kommt Smart App Control um die Ecke Das Problem ist aktuell jetzt nur, dass ich es nicht automatisiert hinbekomme, dass die Smart App Control deaktiviert wird. Wie gesagt, mit dem oben genannten RegKey geht das schon. Aber da scheint der Defender nicht mitzubekommen das die Smart App Control ausgeschaltet wurde und läuft im passiv Modus weiter und braucht System Ressourcen und kann zu Problemen führen. EDIT Problem gelöst. Ich hoffe das hilft auch anderen - hat mich einen verdammten Tag gekostet dieses Problem zu lösen und dann hat es sich wenigstens gelohnt alles zu dokumentieren Man kann den Reg Key setzen und somit die Smart App Control auf deaktiviert setzen [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI\Policy] "VerifiedAndReputablePolicyState"=dword:00000000 Wichtig ist nur, dass man danach noch CiTool.exe -r ausführt. Damit wird dann auch de MS Defender Antivirus deaktiviert, da damit wohl Policies neu eingelesen werden. Nun steht auch mit Get-MPComputerStatus" beim Wert AMRunningMode ein "not running". Der Defender Dienst ist beendet und die MsMpEng.exe läuft nicht mehr. Zu finden hier: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/appcontrol#app-control-and-smart-app-control Das Ganze ohne irgendwelche halbgaren workarounds die am Ende vielleicht nur mehr Probleme machen. Das Vorgehen ist so zumindest von MS offiziell dokumentiert. Warum MS einem das so schwer macht... naja anderes Thema Schönes WE

Ich konnte das Problem lösen. Wir haben die SmartAppControl bisher über folgenden RegKey deaktiviert [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI\Policy] "VerifiedAndReputablePolicyState"=dword:00000000 Das hat auch dazu geführt, dass die SmartAppControl im Security Center deaktiviert wurde. Allerdings scheint der Defender darüber nicht informiert worden zu sein. Wenn wir die SmartAppControl über die GUI deaktivieren, wird auch sofort der Defender deaktiviert. Somit passt dann auch die Info von der MS Seite. Die SmartAppControl muss nicht nur wegen dem Defender bei uns deaktiviert werden, auch hat das deaktivieren dieser Funktion dazu geführt, dass die Fehlermeldung der Anwendung nicht mehr auftritt. Wir hatten genau diesen Fehler hier (nur die Software ist eine andere) https://kb.grutzeck.de/content/41/491/de/beim-starten-von-ag_vip-sql-kommt-die-meldung-webview2loaderdll-ist-entweder-nicht-fuer-die-ausfuehrung-unter-windows-vorgesehen-oder-enthaelt-einen-fehler.html Sobald die SmartAppControl ausgeschaltet ist, geht auch die Anwendung sauber auf. Da wir BitDefender als Endpoint Protection nutzen, brauche ich das ganze "MS Feature Feuerwerk" in Bezug auf Defender nicht. Kennt jemand noch einen anderen Weg die SmartAppControl automatisiert zu deaktivieren? Ich würde nur ungern beim imagen der Geräte immer manuell am Ende die Einstellung deaktivieren

Sorry, hätte ich gleich so schreiben sollen :) Im NTLM Logging haben wir das jetzt auch so nachvollziehen können. Aktuell fällt es auf NTLM zurück, wenn wir über einen DNS Alias zugreifen und kein SPN gepflegt ist. Ist der SPN gepflegt läuft alles sauber über Kerberos. Dann haben wir ein bisschen Arbeit vor uns. Danke für eure Hilfe!

Hallo zusammen, ich habe das Thema schon bei MS im Forum und bei Administrator.de gepostet, aber vielleicht habt ihr ja noch eine Idee oder kennt das Verhalten. https://answers.microsoft.com/en-us/windows/forum/all/defender-not-disabled-with-third-party-av-still/7068cc77-219f-4743-a693-46d43b37bd99 https://administrator.de/forum/windows-11-microsoft-defender-deaktivieren-669689.html wir sind gerade dabei bei uns im Unternehmen Windows 11 zu testen (23H2). Als Endpoint Protection nutzen wir BitDefender Endpoint Security Tools Unter Windows 10 22H2 zeigt uns der Befehl "Get-MPComputerStatus" beim Wert AMRunningMode ein "False" an. Das erwarte ich auch soweit, da ja eine andere AV Lösung installiert ist. Bedeutet also, dass der Defender komplett deaktiviert ist. Auch läuft dort kein MsMpEng.exe und der Dienst Microsoft Defender Antivirus-Dienst steht auf Manuell und läuft nicht. Soweit so gut - das erwarte ich auch so und entspricht auch der MS Doku. Unter Windows 11 23H2 sieht das ganze so aus Get-MPComputerStatus zeigt beim Wert "AMRunningMode" ein "Passive Mode" an. Es läuft weiterhin MsMpEng.exe und auch der dazugehörige Dienst läuft. Ich sehe im Process Monitor haufenweise Zugriffe vom MS Defender. Hier schreibt MS was die unterschiedlichen Modi beim AMRunning mode bedeuten. https://learn.microsoft.com/en-us/defender-endpoint/microsoft-defender-a ... Das ein AV weiterhin lesend auf die Daten zugreift, obwohl er eigentlich deaktiviert ist (so steht es auch im Security Center) macht für mich keinen Sinn, aber das ist ein anderes Thema. Ich war nur sehr verwundert, dass er überhaupt im Passive Mode läuft, da MS hier die Voraussetzungen dafür erklärt. https://learn.microsoft.com/en-us/defender-endpoint/microsoft-defender-a ... Hier schreibt MS, dass der Defender eigentlich deaktiviert wird, wenn Win 11 mit einem third party AV betrieben wird und Smart App Control deaktiviert ist. Smart App Control haben wir per RegKey deaktiviert und third party AV ist installiert und wird korrekt im Security Center erkannt. Und auf der gleichen Seite schreibt MS weiter unten noch folgendes Defender wird deaktiviert wenn man einen third party AV installiert und kein Defender for Endpoint nutzt. Wenn ich richtig informiert bin, ist Defender for Endpoint doch eine kostenpflichtige Cloud Lösung von MS die bei bestimmten Plänen schon enthalten ist. Wir nutzen das nicht. Kann mir einer erklären warum trotzdem der Defender Dienst läuft und der AMRunning Mode nicht auf "false" oder "disabled" steht sondern auf "passive mode"? Mir wäre das erstmal gar nicht aufgefallen. Wir haben aber Probleme mit einer Software, die schmeißt einen Fehler beim starten. Hier ist mir beim troubleshooten im Process Monitor aufgefallen das der MS Defender Antivirus sehr viele Zugriffe auf die Datei macht. Abgesehen davon, soll eine Software auch deaktiviert sein, wenn die Hersteller Doku das so auch kommuniziert. Oder verstehe ich hier irgendwas komplett falsch?

Danke für den Tip, dass ist ja in der Tat so einiges und deckt unsere Vorgaben zu 100% erstmal ab. (das ist das Attribut sPNMappings, richtig?). Diese Liste hatte ich tatsächlich jetzt auch schon gefunden. Das war für mich nur nicht so richtig hilfreich, da ich mir eine Tabelle gewünscht hätte, in der dann steht "service class cifs" wird genutzt für "smb" usw. Aber da habe ich wahrscheinlich zu hohe Ansprüche bzw. zu wenig Wissen um mit der Liste etwas anfangen zu können So steht in der Liste z.b. www und http - da würde ich jetzt erstmal nicht wissen welche der Klassen jetzt für eine Webseite zu nutzen ist. Aber dafür gibt es dann ja google Genau - deswegen wollen wir jetzt die SPNs pflegen und dann Stück für Stück schauen wie wir NTLM abschalten können und haben dann hoffentlich im Bereich der SPNs keine böse Überraschung mehr.

Danke euch, dass war so auch mein Verständnis, habe mich da dann etwas falsch ausgedrückt. Bei uns ist NTLM noch nicht deaktiviert, daher fällt die Authentizierung dann darauf zurück und der falsche/fehlende SPN fällt aktuell noch nicht auf. Das wollen wir jetzt eben korrigieren und erstellen die SPNs. Das heißt dann aber, ich muss wirklich den passenden SNP mit der richtigen Service Class erstellen. Wie nun schon mehrmals geschrieben, HTTP für Web, CIFS für SMB usw. Das ist doch soweit richtig, oder? Muss ich einen zusätzlich SPN dann überhaupt für die Service Class "Host" definieren? Wenn ich es jetzt richtig verstehe, ist das ja dann gar nicht notwendig. Ich muss dne SPN nur für die entsprechende Service Class (SQL, Web, SMB, usw) eintragen. Sorry wenn ich mich hier grad etwas blöde anstelle....

Ich versuche es mal kurz zu erklären. Wir haben früher, z.B. für Web URLs oder SMB Shares, einfach einen weiteren DNS Alias erstellt und diesen auf den Host zeigen lassen. Das hat auch erstmal problemlos funktioniert. Mit der Zeit habe ich dann gelesen, dass dies nicht die Beste Lösung ist, da dies z.B. zu Problemen bei der Kerberos Authentifizierung führen kann und man für solche Punkte immer einen SPN erstellen soll. Wenn wir jetzt also eine neue Webseite oder Webserver in Betrieb nehmen und die Webseite nicht über https://server.domain.local aufgerufen werden soll, sondern über https://applicationname.domain.local, dann erstellen wir einen SPN mit applicationname.domain.local. Das haben wir bisher mit NetDom gemacht. Mit dem NetDom Befehl wurde der neue SPN hinzugefügt (und zwar für alle bestehenden service classes wie host, restrictedkrbhost, termserv, wsman, usw). Mit SetSPN muss ich jetzt ja die service class mit angeben. Wenn ich also für eine Webseite einen SPN erstelle, muss ich HTTP/applicationname angeben. Was ich mich jetzt nur Frage, wie wichtig ist die service class? NetDom hat für einen Webseite ja auch kein HTTP/ hinzugefügt, sondern nur die bestehenden service classes um den neuen SPN erweitert (also host/applicationname, termsrv/applicationname, usw) und kein HTTP/applicationname erstellt. Oder stehe ich hier grad komplett auf dem Schlauch und verdrehe etwas? Für mich ist ein SPN ein weitere "Name" über den das Computerobjekt angesprochen werden kann.

Eine Frage ist mir noch eingefallen. Gibt es eigentlich eine Liste der Service Classes für die SPNs? Ich habe dazu irgendwie nur die allgemeine Info von MS gefunden https://learn.microsoft.com/en-us/windows/win32/ad/name-formats-for-unique-spns Das klingt für mich so, als könnte ich beliebig wählen was ich dort eintrage. Aber was genau macht diese dann, wenn ich das einfach beliebig erstellen kann. Oder versteh ich hier was falsch? Wenn wir bisher einen weiteren SPN für einen Server z.B. für einen SMB Share oder eine Webseite benötigt haben, dann hatten wir ja nur den netdom Befehl ausgeführt. Dieser hat dann den SPN gesetzt und auch den DNS Alias erstellt. Der Befehl hat dann einfach für alle bestehenden service classes auf dem entsprechenden AD Objekt die SPNs eingetragen. Als Beispiel Auf einem Server haben wir den SPN server1 mit dem netdom Befehl hinzugefügt. In dem Server AD Objekt wurde dann HOST/server1 RestrictedKrbHost/server1 Termsrv/server1 WSMAN/server1 hinzugefügt. Ist das jetzt komplett falsch? Mit SetSPN müsste ich ja den Service angeben. Das heißt wenn ich das für einen SMB Share mache, gebe ich als service CIFS/ an. wenn ich das für einen Webserver mache, gebe ich HTTP/ an, usw. Oder reicht es auch, einfach nur HOST/ anzugeben? Bin grad etwas verwirrt

Danke euch! Ich schaue mir das Thema mal etwas genauer an. Am Ende macht man mit SetSPN erstmal nichts falsch, gerade wenn man nicht zu 100% weiß was man tut. Da hast du Recht, Evgenij.

Das mit Set-ADxyz ist natürlich der einfachste Weg, dass stimmt. Ich dachte immer, dass man die speziellen Tools wie netdom oder eben SetSPN dafür nutzen muss, da man sonst mehrere manuelle Schritte durchführen muss. Aber dann schaue ich mir Set-AD mal an. Wenn wir jetzt bei dem Thema schon sind, vielleicht kann mir jemand die Frage auch beantworten :) Ich muss ja dann eine "Service class" mitgeben. Hier steht ja z.b. dann HOST/ oder RestrictedKrbHost/ mit dabei. Wir setzen den SPN vor allem für Webservcies oder SMB Shares. Da reicht dann ja ein HOST oder irre ich mich da?

Hi Martin, danke dIr! Dann nutzen wir ab sofort auch nur noch SetSPN. Soweit ich das verstanden haben, nutzt man die SPNs ja auch nur wegen der Kerberos Authentifizierung und da reicht es ja, wenn in der AD die Einträge gesetzt werden. Gruß, Steffen

Vielen Dank Martin. Ich habe jetzt auch rausgefunden woran es liegt, dass ich mit dem Domänen Admin "Zugriff verweigert" beim abrufen der SPNs mit dem NetDom Befehl erhalte. Bei uns sind die Domänen Admin Accounts auf den Servern und Clients aus der "Administratoren Gruppe" entfernt. Der NetDom Befel benötigt aber wohl die administrativen Rechte um den SPN auszulesen, da ich ja remote auf den Server zugreifen würde (meine Vermutung). Wenn ich den Domänen Admin in die "Administratoren Gruppe" aufnehme, funktioniert auch der NetDom Befehl. Wenn ich es also richtig sehe, dann fragt der setspn Befehl die Infos direkt aus dem AD Objekt ab, der netdom Befehl fragt diese dann wohl vom Server direkt ab. Das ist wahrscheinlich die Info vom Martin, dass Netdom WinNET-Provider nutzt und SetSPN ADSI nutzt. Ich dachte auch immer, dass beim SPN setzen auch lokal auf der Maschine was verändert werden muss und das mit dem netdom Befehl automatisch durchgeführt wird. Die Info hatte ich hier gefunden: https://woshub.com/add-alternate-computer-name-windows/ Macht das der setspn auch oder setzt der nur den Wert im AD Objekt und ich müsste den registry parameter dann manuell auf dem entsprechenden Server setzen? Grüße

Top, danke dir. Dann werden wir in Zukunft SetSPN verwenden und nicht mehr netdom. Mich wundert es zwar immer noch, warum es bei netdom den "Zugriff verweigert" Fehler gibt, aber mir fehlt die Zeit das jetzt zu klären :) Das die Berechtigungen passen, sieht man ja eigentlich am funktionierenden SetSPN Befehl. Schönen Abend Dir.

Hi Jan, ha...das ist ja faszinierend. Damit funktioniert es. Das heißt dann wohl auch, dass wir setspn auch zum setzen der SPNs nehmen sollten und nicht mehr netdom, oder? Wenn ich es richtig sehe, ist netdom dann die "alte" Variante? Ich war einfach nur verwundert, da das setzen der SPN bisher damit immer gut funktioniert hat. Nur beim auslesen ist nun aufgefallen, dass es bei unterschiedlichen Usern plötzlich Probleme gab (obwohl deren Berechtigung auf die AD Objekte identisch waren). Gruß, Steffen

Hallo zusammen, ich habe folgends Problem bzw. verstehe das Verhalten nicht so ganz. Wir haben bei einigen Windows Server 2019 Servern den SPN über den Netdom Befehl eingetragen. Das Auslesen des SPN über "netdom computername <server name> /enum" funktioniert dann manchmal mit dem Domänen Administrator und manchmal mit unseren "Server Admins". Die Fehlermeldung lautet dann einfach nur "Zugriff verweigert". Ein wirkliches Muster habe ich noch nicht rausgefunden. Beide User haben auf das Attribut "msDS-AdditionalDnsHostName" Leserechte. Soweit ich das verstehe, sollte das doch ausreichen um mit dem oben genannten Befehl den SPN auszulesen. Schreibrechte auf das Attribut brauche ich ja nur, wenn ich den SPN mit dem User setzen will. Aber auch das Rechte hätte der User. Oder was für Voraussetzungen müssen noch gegeben sein, damit man den SPN auslesen kann? Vielen Dank Grüße

Haben jetzt den download mode auf 99 gestellt. Updates vom Teams Client funktionieren nun und auch die WSUS Anbindung scheint weiterhin wie gewohnt zu gehen. Danke Dir!

Hallo zusammen, ich habe mal eine kurze Frage zum Download Mode der Delivery Optimization Einstellung Aktuell nutzen wir den download mode 100 (Bypass) da wir keine Delivery Optimization benötigen und die Downloads über WSUS bereitgestellt werden. Dual Scan ist deaktiviert. Nun ist es so, dass der neue MS Teams Client über DO 100 keine Updates laden kann. Dqs wird auch bei MS so kommuniziert. https://learn.microsoft.com/en-us/microsoftteams/new-teams-bulk-install-client#prerequisites-for-target-computers Wir überlegen nun den MS Teams Client manuell über unser Client Management zu aktualisieren oder den DO Mode umzustellen. Bei MS habe ich dazu folgende Tabelle gefunden https://learn.microsoft.com/en-us/windows/deployment/do/waas-delivery-optimization-reference#download-mode So ganz schlau werde ich daraus aber noch nicht. Mode 100 verstehe ich ,hier wird BITS verwendet und keine Delivery Optimization. Mode 0 würde zwar peer-to-peer deaktiveren, aber trotzdem HTTP Anfragen zu MS durchführen Mode 99 deaktivert Delivery Optimization - also keine Kommunikation zu MS (so würde ich es verstehen), aber trotzdem wird gesagt ->In this mode, Delivery Optimization provides a reliable download experience over HTTP from the download's original source or a Microsoft Connected Cache server, with no peer-to-peer caching Ist das nicht ein Widerspruch? Einmal wird gesagt DO ist deaktiviert und dann wird erwähnt das DO wird in diesem Mode verwendet um aus der original Quelle Daten nachzuladen (das wäre dann ja MS oder wäre da mit der WSUS gemeint?) Was wir wolle ist einfach ein download der Updates über den WSUS ohne jegliche MS Konnektivität (so wie es jetzt mit Mode 100 funktioniert). Oder ist das mit den anderne Modi gar nicht möglich? Was hätte Mode 99 für einen weiteren Nachteil? Danke schon mal im Voraus. Grüße

Danke für den kurzen Erfahrungsbericht. Dann ist für uns LTSC auch erstmal raus. Wir setzen auch DELL Geräte ein und haben einige Schnittstellen die Treiber benötigen und einiges an Third-Party Software. Dazu kommt, dass wir nicht bei jedem Update von einer LTSC zur nächsten eine komplette Neuinstallation durchführen wollen. Da der LTSC Support ja auch von 10 auf 5 Jahre reduziert wurde, ist das auch kein großes Argument mehr. Mal abgesehen davon, dass es ja aktuell noch gar keine Win 11 LTSC gibt. Dann prüfen wir noch mal den genauen Unterschied zwischen Pro und Enterprise und werden dann wohl hier eine Entscheidung treffen. Danke für die Rückmeldung. Wir haben das schon mal durchgerechnet und uns die MS Pakete angeschaut. Natürlich können wir damit viel bisherige Services ablösen, die Frage ist nur - wollen wir wirklich alles über MS Produkte lösen (meine Meinung ist dazu - nein) - wer soll diese Migrationen durchführen (da bräuchte ich 1-2 zusätzliche Mitarbeiter die nur mit der Migration der Systeme beschäftigt sind - Mail Gateway, Patch Management, EMM/MDM, Endpoint, Project Management, usw). Das können wir aktuell nicht stemmen und zum anderen sind wir mit den Produkten auch nicht unzufrieden. Aber das ist ein anderes Thema :)

Hallo zusammen, wir planen aktuell die Migration zu Windows 11. Aktuell laufen bei uns alle Clients mit Windows 10 Pro 22H2. Die Frage die wir uns aktuell stellen ist, werden wir auch bei Windows 11 auf Pro gehen oder vielleicht doch auf Enterprise bzw. LTSC. Ich habe bei MS jetzt keinen direkten Vergleich von Pro und Enterprise gefunden. Ich habe mit jetzt mal an diesem Vergleich orientiert und da wäre jetzt der Aufpreis für Enterprise für uns nicht wirklich lohnenswert. https://www.xda-developers.com/windows-11-pro-vs-enterprise/ Es war zwar auch schon bei Win 10 so, dass einige GPOs nur mit Enterprise funktioniert haben, aber auch das konnten wir ganz gut abfedern. So wie ich es sehe, ist für uns einer der Hauptgründe die etwas längere Supportzeit. Enterprise 36 Monate Pro 24 Monate Die LTSC wäre dann ja noch mal länger im Support, richtig? Hier wären es dann 5 Jahre und die Windows Funktionen bleiben auf dem Stand des Releases und werden nicht wie bei Pro und Enterprise immer weiter aufgebläht. So wie ich das aber aktuell sehe, gibt es noch gar kein Windows 11 LTSC, dass soll wohl erst noch kommen. Was wir hier brauchen ist ein stabiles OS, ohne großen Schnickschnack wie Copilot, Windows Store, Wetter Apps usw. Kann man die Unterschiede grob so zusammenfassen? LTSC -> OS auf die wichtigsten Funktionen reduziert, langer support Enterprise -> OS kann etwas feiner per GPOs administriert werden als die Pro, größerer Funktionsumfang für Unternehmen, etwas längerer Support Pro -> OS mehr oder weniger wie in Consumer OS mit dem kürzesten Support Eine Frage hätte ich noch zur LTSC Version. Wie war das bei der Win 10 Version. Wenn ich einen Client auf Win 10 1809 LTSC hatte und wollte den dann auf Win 10 21H2 bringen. Konnte ich das einfach per InPlace Upgrade machen? Brauchte ich für das Update dann wieder eine neue Lizenz? Danke euch. Grüße, Steffen P.s. Abo Lizenen wie M365 E3 / E5 usw stehen bei uns aktuell nicht zur Debatte.

Interessant - das gleiche Problem haben wir immer mal wieder auch. Den RegKey werde ich mal ausprobieren. Danke Dir. Das Thema werde ich mal unseren Fortigate Kollegen geben. Danke!

Die "Wait for network" GPO haben wir eigentlich auf allen Clients aktiviert und diese greift auch für VPN Clients https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.WindowsLogon::SyncForegroundPolicy Wir sprechen ja von dieser GPO, richtig? Cloud joined ist bei uns nicht möglich, wir sind nicht in der Azure/EntraID Welt und werden das auch zeitnah nicht sein. Ob das jetzt gut oder schlecht ist würde ich hier gerne nicht diskutieren

Alles klar. Das heißt ein Großteil der VPN Lösungen ist davon betroffen, wenn die nicht bei der Anmeldung warten bis wirklich die VPN Verbindung steht und die DCs befragt werden können. Gut zu wissen. Ich werde beim Support mal nachfragen ob man hier irgendwie eine Verzögerung definieren kann. Danke für die Hilfe.

Uff...jetzt stehe ich irgendwie auf dem Schlauch. Aber MS sagt ja extra, wenn Gruppenmitgliedschaften bei einer VPN Verbindung nicht aktualisiert werden, soll man die VPN Verbindung vor dem Login aufbauen. Das wäre, nach meinen Verständnis, ja bei uns gegeben, da der FortiClient erst die VPN Verbindung aufbaut und dann die Windows Anmeldung durchführt. Wenn ich dich jetzt aber richtig verstehe, ist aber auch in dieser Konstellation (da die Anmeldung zu schnell nach der VPN Verbindung hergestellt wird) der Fehler nicht wirklich gelöst. Man müsste somit erst eine VPN Verbindung aufbauen, kurz warten und dann die Windows Anmeldung durchführen, richtig? Wenn ich dich also richtig verstehe, gibt es keine wirklich Lösung für das Problem? Außer man sperrt den Bildschirm nach der Anmeldung, entsperrt den Bildschirm und meldet sich ab und wieder an. Das hatte bei uns zumindest geholfen.

Danke für den Tipps und Hilfestellungen. Wir beobachten das Verhalten jetzt erstmal weiter. Möglicherweise ist es wirklich nur das Verhalten bzw. die Trägheit von whoami /groups.

Hi Nils das ist bzw. war auch meine Vermutung und das versuche ich gerade mit dem Support rauszufinden. Allerdings bin ich jetzt doch noch mehr verwirrt. Bei den letzten 2 Tests hat es jetzt plötzlich funktioniert. Neue AD Gruppe erstellt. Meinen User hinzugefügt Von Windows abgemeldet und Anmeldung inkl SSL VPN whoami /groups hat jetzt dann die neue Gruppe angezeigt puh....gibt es irgendeine Einstellung mit der definiert wird, wie lange die Verbindung zum DC dauern darf bis eine zwischengespeicherte Anmeldung verwendet wird? Meine Vermutung ist, dass vielleicht manchmal die Connection einfach etwas zu langsam ist und der Client (trotz bestehender DC Verbindung) meint er ist offline. Gruß, Steffen Edit: Ein kurzer Nachtrag. bei dem command whoami /groups werden Gruppen unterschiedlich dargestellt einige Gruppen sind als "Typ" Gruppe angegeben und einige als "Alias" und werden bei den Gruppen als "Lokale Gruppe" angezeigt. So z.B. auch meine Test Gruppe die dem User schon längst entzogen wurde. Aber auch andere Domänen Gruppen werden als "Alias" und "Lokale Gruppe" angezeigt. Andere Domain Gruppen werden eben als "Gruppe" und ohne "Lokale Gruppe" angezeigt. Ist das normal bzw. was ist hier der Unterschied? Heißt das Attribut "Lokale Gruppe" wirklich, dass der Client diese Gruppen als lokale Gruppe ansieht und nicht als AD Gruppe?