Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 37 subscribers
  • Views 4479 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

AD SSO bringt Fehler

uziegler
Hallo @All,

seit Heute habe ich das Problem, dass der Proxy keine Authentifizierung gegen das ADS mehr hinbekommt. Jeder Zugriff über den Proxy wird mit "Access denied" quittiert. Der zugehörige Protokollauszug sieht dann so aus:

2014:03:10-13:05:16 fw-gate httpproxy[5069]: id="0003" severity="info" sys="SecureWeb" sub="http" request="0xdf12490" function="adir_auth_process_negotiate" file="auth_adir.c" line="1108" message="gss_accept_sec_context: Key table entry not found"

Ich habe die Firewall bereits neu in die Domäne aufgenommen, ohne den erhofften Erfolg. Die Schreibweise des FQDN habe ich ebenfalls abgeglichen, da ist auch alles IO. Unsere Firewall läuft im Standard-Modus und die Domäne ist Win2k3. 

Als Übergangslösung habe ich die Authentifizierungsmethode von "AD SSO" auf "Keine" umgestellt. Soweit ist erst mal das Symptom abgeschaltet. Jetzt greifen natürlich die userbezogenen Profilfilter nicht mehr, aber das kann ich temporär verkraften.

Kann mir bitte jemand bei der Lösung dieses Problems behilflich sein?
Herzlichen Dank und eine ruhige Nacht!

U Ziegler


This thread was automatically locked due to age.
  • 0
    Hi uziegler,
    was ist seitdem passiert?

    Wenn du über "Definitionen & Benutzer" - Authentifizierungsdienste - Kartei "Server" gehst, kannst du deine Verbindung testen, ob diese Funktioniert.

    Hast du einen User eingetragen, der im AD leserecht hat?
    Diesen benötigst du.

    Nice greetings
  • 0 in reply to GuyFawkes
    Hi GuyFawkes,
    den Authentifizierungstest habe ich bereits mit unterschiedlichen Usern durchgeführt, alles IO. Und als Bind-DN steht der Admin drin, auch dieser Test ist erfolgreich.

    Passiert ist ein OS-Wechsel an einigen Clients von XP zu W7... kann nach meiner Meinung kein derartiges Problem verursachen. Andere Clients laufen schon länger mit W7.

    Dann habe ich noch von UTM 9.107 auf 9.108 und direkt danach auf UTM 9.109 upgedated. Das wäre theoretisch als Ursache möglich. Allerdings ist das jetzt 2 Wochen her und erst seit dem Wechsel der Client-OS tritt das Problem auf.

    Weiter wurde in zeitlichem Zusammenhang ein W2k8-Server als einfacher Member-Server in Betrieb genommen, der hat aber keine Domänenfunktionen. Evtl. hat der Kollege die GP-MMC angestartet. Ich kann zwar nicht ausschließen, dass er die Gruppenrichtlinien angefasst hat, aber das wäre schon ziemlich daneben...wenn ich so drüber nachdenke kommt das dem Problem schon ziemlich nahe...Administration von einem W2k3-Server und parallel von einem W2k8-Server klingt nach Verwirrungen...
    Wäre es in dem Fall besser, den W2k8-Server hochzustufen und die Administration auf diesen Serever zu verlegen?
    Und wie kann ich die Kerberos-Authentifizierung der UTM detailliert prüfen?

    Oh Ha, das wird scheinbar doch nicht so einfach. Trotzdem schon einmal Danke für weitere Gedanken und Anregungen.
  • 0
    Du könntest mal noch versuchen das AD per LDAP auszulesen, ob das funktioniert

    SSL = Ja
    Port = 636
    Bind DN = administrator@domain.local
    Password = deinpw
    Attribute custom = sAMAccountName
    Base DN = OU=deineou,DC=domain,DC=local
    Username = leer (da über bind dn)
    Pass = leer


    PS. Wenn der 2008er Server als reiner Memberserver fungiert, kann ich mir auch nicht erklären woher das Problem plötzlich kommt. Die GPOs sollten hierdurch auch nicht angepasst worden sein.

    Gruß
  • 0 in reply to wiLLow
    Das führt zum identischen Verhalten wie bei ActiveDirectory-Zugriff, die Tests funktionieren ohne Murren; das SSO verweigert die Authentifizierung.
  • 0
    Werden die Benutzer denn richtig aktualisiert? Kannst du im AD vielleicht mal einen Testuser anlegen und schauen ob dieser gesynct wird?
  • 0 in reply to wiLLow
    Das habe ich schon ausgetestet. Ich habe einen User WILLI.TEST im AD erstellt und diesen dann zur Anmeldung genutzt. Beim Zugriff auf das INET wurde der User auf der Astaro angelegt und das User-Portal automatisch berechtigt. Dann habe ich kontrolliert, ob WILLI in die Rechtegruppe der AD-Nutzer integriert wurde. Hat auch funktioniert. Nur der Zugriff auf das Internet wird mit Access Denied wegen Auth-Problemen abgewiesen.

    Ich weiß grad nicht mehr weiter...
  • 0
    Welche Gruppe hast du im Proxy freigegeben bzw. den Zugriff erlaubt?
    Domänen-Benutzer bzw. die primäre User Group?

    Nice greetings
  • 0 in reply to GuyFawkes
    Die Gruppe der "Active Directory Users" ist zugriffsberechtigt --> und jetzt funktioniert es auch wieder. Ich habe die Gruppe noch einmal raus und wieder rein genommen und (evtl. war das die Ursache) ich habe bei den Usern die BackEnd-Sync aktiviert. Also ist jetzt alles wieder so wie vor dem Problem, nur daß es jetzt wieder funktioniert.

    Kann mir das einer erklären?

    Dennoch herzlichen Dank für die Unterstützung!
  • 0
    Ja, ich gehe davon aus, dass du die primäre User Group genommen hast. Kannst es im AD Objekt unter Groups sehen, da steht dann, welche User Group die primäre ist.

    Leg bitte eine extra Gruppe an z.B. GL_Alle oder GL_IE_Users 
    Diese Gruppe nutz bitte in der UTM, dasselbe gilt auch bei SSL VPN, dort auch extra Gruppen anlegen.

    Sonst wirst du früher oder später wieder Probleme bekommen.

    Nice greetings
  • 0 in reply to GuyFawkes
    "Früher oder Später" war am Freitag. Das Problem bestand wieder mit dem Unterschied, dass nun die LDAP-Anmeldung nicht mehr funktionierte. Also habe ich die Suche auf den DC ausgeweitet und festellen müßen, dass unser DNS (AD-Integriert) mehrere Fehler ausgegeben hat. Nach Korrektur der Selben scheint das AD-SSO jetzt wieder korrekt zu funktionieren.
Unfiltered HTML