AD Authentification & SSO bei Web-Proxy

...
Das erste problem ist das bei aktiviertem SSO unter Zuweisung der Gruppe trotzdem jeder den Proxy verwenden kann und nicht nur die Gruppe. Das zweite Problem ist, das zeitweise immer diese Authentifizierungsfenster beim user aufpoppen und er sich erneut Authentifizieren muss. Ist das Astaro typisch oder sollte das nicht so oft bzw. gar nicht passieren.
...

zu deinem erstem Problem: wahrscheinlich hast du kein entsprechendes Profil angelegt, welches AD-Usern die nicht in der Gruppe sind, das surfen verbietet.

Ähnliche Aufgabenstellung habe ich so gelöst:
Web Security->Http->Content Filter -> Block content aktiviert und unten alles nicht angehackt
Web Security->Http-Profiles->Filter Action-> Neues Profil -> Proxy_Erlaubt ->  Mode allow by default
Web Security->Http-Profiles->Filter Assignments-> neuer Filter -> User_aus_AD -> die entsprechende Gruppe  und Filter Action -> Proxy_Erlaubt
Web Security->Http-Profiles->Proxy Profiles-> neues Profil -> Filter Assigments -> User_aus_AD , Fallback Action -> default Filter Action

Zu dem zweitem problem:
Ändere die Proxykonfiguration im Client auf den DNS-Namen der Firewall, anstelle von IP.

Gregor Kemter

@modwheel
Per Gruppenrichtlinie ist die FQDN der ASG als Proxy auf allen Clients erzwungen. Alle Clients und die ASG haben ein Computerkonto in der Domäne und stehen im AD-integrierten DNS.
Bei Rechnern, die nicht in der Domäne sind, bekomme ich auch AuthPopups. 

wahrscheinlich hast du kein entsprechendes Profil angelegt, welches AD-Usern die nicht in der Gruppe sind, das surfen verbietet.

Laut HTTP-Profiles-Guide ist es nicht nötig ein solches Profil anzulegen. Sprich es sollte auch ohne eine solche Regel funktionieren. Allerdings steht auf Seite 9 auch die IP und nicht die FQDN der ASG als Proxy drin [:D] 

Each user in the AD group RnD must now enter the IP address of Astaro Security Gateway and the
HTTP port number in his or her Internet Options proxy server settings (see Figure 8).

Q: What happens if no profile, not even the default profile matches?
A: In this case the request will be blocked.

Gibt es eine Doku, die gegenteiliges aussagt? 
Ich habe debug-Modus des Proxy von none auf users;auth gestellt und werde heute das Logfile zur Auswertung an den Astarosupport senden. Mal schauen was dabei rauskommt. 

Gruß

Eigentlich sollte die IP der Firewall reichen, ich habe aber speziell bei Vista die Erfahrung gemacht, daß mit IP öfters das AnmeldeFenster kam. (mit FQDN war das Problem weg)

Ob die Proxy-Docu aktuell ist, kann ich nicht beurteilen, hatte aber die selbe Frage während der Betatests zu 7.100 gestellt.

Gregor Kemter

@modwheel
Per Gruppenrichtlinie ist die FQDN der ASG als Proxy auf allen Clients erzwungen. Alle Clients und die ASG haben ein Computerkonto in der Domäne und stehen im AD-integrierten DNS.
Bei Rechnern, die nicht in der Domäne sind, bekomme ich auch AuthPopups. 

 

Genau so habe ich es auch gemacht, computer konten für alle und im dns die astaro hinterlegt. Hast Du AD über SSL oder normal verwendet?

Bei welchen Browsern habt Ihr die Probleme mit auth ?
Beim IE sollte es keine Probleme geben, beim Firefox spinnt das Single-Sign-On manchmal.
Weiterer Punkt ist die Sicherheitsrichtlinie (NTLMV2 als Stichwort).

Gregor Kemter

Ja beim IE7 hab ich das wirklich überall, Firefox o.ä. benutzen manche auch - dafür hab ich die ntlm option eingetragen.

Selbst mit dem DNS Namen kommen die pop ups zum authentifizieren [:(]

Hallo.

Ich konnte das Problem mit Hilfe des ASG-Supports klären.
Vielen Dank an den fähigen Support an dieser Stelle. [:)]

Der Vorschlag von gkemter mit dem Default-Profile, also den Einstellungen unter Websecurity -> HTTP, alle nicht authentifizierten abzublocken, war richtig. 
Nach dem diese Einstellung gemacht wurde, wurden AD-Benutzer, die nicht in einer der Gruppen mit Backend-MS waren, geblockt. 
Schade das ich dieses Vorgehen in keiner Doku finden konnte.

Die anschließenden Tests mit verschieden granulierten Rechten in Gruppen zeigten jedoch noch Fehler bei einzelnen Benutzern. Die betroffenen Benutzer wurden immer mit dem Default-Profile bedient, obwohl sie authentifizierte Domänenbenutzer waren.

Änderungen im AD soll das SSO-Auth-Caching angeblich alle 21 Minuten auffrischen (15Minuten Netbios, 6Minuten NTLM). Nachdem diese Zeit verstrichen war und das Neustarten der betreffenden Dienste keine Besserung brachte, veränderte der ASG-Support etwas am Samba oder dessen Konfiguration. Danach funktionierte alles wie erwartet. Astaro prüft das nun. Sollte es sich um einen Bug handeln, soll es uU noch ins 7.2er kommen.

Gruß

Hallo.

Ich konnte das Problem mit Hilfe des ASG-Supports klären.
Vielen Dank an den fähigen Support an dieser Stelle. [:)]

Der Vorschlag von gkemter mit dem Default-Profile, also den Einstellungen unter Websecurity -> HTTP, alle nicht authentifizierten abzublocken, war richtig. 
Nach dem diese Einstellung gemacht wurde, wurden AD-Benutzer, die nicht in einer der Gruppen mit Backend-MS waren, geblockt. 
Schade das ich dieses Vorgehen in keiner Doku finden konnte.

Die anschließenden Tests mit verschieden granulierten Rechten in Gruppen zeigten jedoch noch Fehler bei einzelnen Benutzern. Die betroffenen Benutzer wurden immer mit dem Default-Profile bedient, obwohl sie authentifizierte Domänenbenutzer waren.

Änderungen im AD soll das SSO-Auth-Caching angeblich alle 21 Minuten auffrischen (15Minuten Netbios, 6Minuten NTLM). Nachdem diese Zeit verstrichen war und das Neustarten der betreffenden Dienste keine Besserung brachte, veränderte der ASG-Support etwas am Samba oder dessen Konfiguration. Danach funktionierte alles wie erwartet. Astaro prüft das nun. Sollte es sich um einen Bug handeln, soll es uU noch ins 7.2er kommen.

Gruß