Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 31 replies
  • Subscribers 1 subscriber
  • Views 21934 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

'Warned' websites getting 'Authentication Failed' for some users.

jpcurrie
Hi all,

We're using AD SSO with a fairly complex set of filter profiles and allow lists.

Setup:

1.  The profile in question is using standard mode, SSO and 'block access on auth failure', URL filtering only for SSL.

2.  I've deployed the UTM HTTPS CA via GPO

3.  The UTM hostname is resolvable internally to an internal IP address.

4.  The UTM is joined to the domain and has DNS request routing setup so it resolves our internal DNS correctly.

5.  The system time is correct and in sync with our DC's

6.  I've tried both hostname and IP address in the proxy settings


Problem:

Sometimes (I've been unable to find a pattern) when a user is warned, when they attempt to continue, they are presented with a block page saying "Authentication failed").

Has anyone came across this before?  Where could I start to further troubleshoot it?  I'm struggling to fix the issue as you can see!

Another note, I originally configured the 'Certificate for End-User Pages' option, setting it to use our wildcard cert, which entirely broke this process, upon turning it off, the unblock works mostly, but with the above auth bug. 

The bug seems random, with some users getting the auth block randomly

Cheers,

John.


This thread was automatically locked due to age.
  • 0
    Hi,
    sometimes the authentication failure is caused by the link taking too long to download which might explain the random nature of the issue?

    Do you have heavy ftp or a webserver that uses large bandwidth at odd times?

    Ian
  • 0
    Hi John,

    When doing AD SSO in standard mode every request is authenticated.  There may be something funny going on with the Warn / Proceed that is causing the credentials to not be sent across correctly.

    I suspect that this will require packet inspection to figure out what is actually going on.

    Please raise an issue with support.
  • 0 in reply to Michael Dunn
    Hi,
    sometimes the authentication failure is caused by the link taking too long to download which might explain the random nature of the issue?

    Do you have heavy ftp or a webserver that uses large bandwidth at odd times?

    Ian


    Nothing that I can think of, it doesn't seem related to bandwidth/time of day.

    Hi John,

    When doing AD SSO in standard mode every request is authenticated.  There may be something funny going on with the Warn / Proceed that is causing the credentials to not be sent across correctly.

    I suspect that this will require packet inspection to figure out what is actually going on.

    Please raise an issue with support.


    It's a difficult one as I can't reproduce it reliably?
  • 0
    The only thing that comes to my mind is IE versions - does that have any effect or known issues?
  • 0
    I found a few things in using and deploying UTM.

    Make sure all AD Groups are correct in ur UTM Groups.
    - I also noticed the UTM doesnt like nested groups
    ie 'for us at a school we have an 'all students' sec group in AD which contains each sec group for each year level. On the UTM we had to add the year level sec groups not the nest (Hope that made sense).

    to get AD SSO Working on Macs I had issues with our 2012 R2 DC.
    issue is that 2012 and onwards compress user SIDs so when issuing a Kerb Ticket the UTM had issues with the OSX Machine. this was fixed by adding in a registry setting as seen in the bottom of this technet article:
    KDC Resource SID Compression - TechNet Articles - United States (English) - TechNet Wiki

    That then stopped Win AD Auth which was combatted with NTLM Auth:
    Cyberoam Knowledge Base

    Now both have been done our AD SSO works across all devices. this has taken so long to fix and Im glad I came across these unrelated articles.
    I do hope this helps you somewhat.

    We have had to overcome a lot of obstacles but are loving using the UTM now for all routing and firewall with a fibre connection.


    Macca
  • 0
    JP, can you show us a line from Web Filtering where a user received such a message.  What corresponding evidence do you see in the Kerberos log on the DC?

    I've seen more situations like this when NTLM was used.   You definitely want to use the FQDN to get Kerberos auth.

    Cheers - Bob
  • 0
    Hi all,
    Sometimes (I've been unable to find a pattern) when a user is warned, when they attempt to continue, they are presented with a block page saying "Authentication failed").


    Are you using the new "Warn" functionality?  And it is immediately after clicking proceed?

    Can you try this:
    Visit a site that you will be warned.
    Sit on the warning page with no other internet access for 6 minutes.
    Click Proceed.
    Does that reproduce the problem?

    As posted about regarding IE versions, I would more suspect things like plugins and non-browsers (eg updaters).


    Can you post logs of when this occurs?
  • 0 in reply to Michael Dunn
    Guys, thank you for the help.

    I found a few things in using and deploying UTM.

    Make sure all AD Groups are correct in ur UTM Groups.
    - I also noticed the UTM doesnt like nested groups
    ie 'for us at a school we have an 'all students' sec group in AD which contains each sec group for each year level. On the UTM we had to add the year level sec groups not the nest (Hope that made sense).

    to get AD SSO Working on Macs I had issues with our 2012 R2 DC.
    issue is that 2012 and onwards compress user SIDs so when issuing a Kerb Ticket the UTM had issues with the OSX Machine. this was fixed by adding in a registry setting as seen in the bottom of this technet article:
    KDC Resource SID Compression - TechNet Articles - United States (English) - TechNet Wiki

    That then stopped Win AD Auth which was combatted with NTLM Auth:
    Cyberoam Knowledge Base

    Now both have been done our AD SSO works across all devices. this has taken so long to fix and Im glad I came across these unrelated articles.
    I do hope this helps you somewhat.

    We have had to overcome a lot of obstacles but are loving using the UTM now for all routing and firewall with a fibre connection.


    Macca


    We've had a few obstacles too, but overall it seems like a great product.  I think this is the last bug, post install, to be resolved.

    I did try nested and non-nested I think but I will give it another try.


    JP, can you show us a line from Web Filtering where a user received such a message.  What corresponding evidence do you see in the Kerberos log on the DC?

    I've seen more situations like this when NTLM was used.   You definitely want to use the FQDN to get Kerberos auth.

    Cheers - Bob



    2014:04:30-14:31:43 utm httpproxy[10084]: id="0071" severity="info" sys="SecureWeb" sub="http" name="web request warned, forbidden category detected" action="warn" method="CONNECT" srcip="10.0.0.104" dstip="" user="GWA\jpcurrie" statuscode="403" cached="0" profile="REF_HttProContaInterNetwo (GWA Proxy)" filteraction="REF_HttCffItWorkiDay (IT Working Day Filter)" size="3131" request="0x16183760" url="https://itunes.apple.com/" exceptions="av,fileextension" error="" authtime="138" dnstime="0" cattime="84630" avscantime="0" fullreqtime="90688" device="0" auth="2" reason="category" category="112" reputation="neutral" categoryname="Entertainment"
    2014:04:30-14:31:43 


    Above is the log, there is nothing else afterwards.  Good idea about the Kerberos log, I've just enabled it and will post back.

    Are you using the new "Warn" functionality?  And it is immediately after clicking proceed?

    Can you try this:
    Visit a site that you will be warned.
    Sit on the warning page with no other internet access for 6 minutes.
    Click Proceed.
    Does that reproduce the problem?

    As posted about regarding IE versions, I would more suspect things like plugins and non-browsers (eg updaters).


    Can you post logs of when this occurs?


    Log above, I will try that now and post back.  At this point it's worth mentioning that I made contact with support and the ticket # is 4399577. 

    I've sent them tcpdump and wireshark logs and they have escalated it beyond level one.

    -edit Yes the problem is the same after waiting 6 minutes.
  • 0
    Thanks JP, that is enough information that I reproduced internally.  I will look into this.

    I think the issue is is a doing a warning/proceed on an https site.
  • 0 in reply to Michael Dunn
    Thanks JP, that is enough information that I reproduced internally.  I will look into this.

    I think the issue is is a doing a warning/proceed on an https site.


    Wow, thanks!

    I had a feeling it might have been HTTPS.

    Another bit of info, following on from the Kerberos log suggestion:


    We're running a old 2003DC still which I need to get rid of (the auth Server for the UTM is a 2008R2 box though), so are still in 2003 functionality mode?


    A Kerberos Error Message was received:
     on logon session 
     Client Time: 
     Server Time: 15:55:13.0000 5/2/2014 Z
     Error Code: 0xe KDC_ERR_ETYPE_NOTSUPP
     Extended Error: 
     Client Realm: 
     Client Name: 
     Server Realm: GWA.WIN2000
     Server Name: krbtgt/GWA.WIN2000
     Target Name: krbtgt/GWA.WIN2000@GWA.WIN2000
     Error Text: 
     File: 9
     Line: f09
     Error Data is in record data.


    http://blogs.technet.com/b/askds/archive/2012/07/27/kerberos-errors-in-network-captures.aspx



    KDC_ERR_ETYPE_NOTSUPP 

    Here, the client has requested a ticket from the domain controller with a specific algorithm of which the domain controller does not have a hash. In the request, the client will list all the algorithms it supports. The domain controller will pick the highest one that it supports and returns the ticket encrypted with that algorithm. If there are no matches, the domain controller returns KDC_ERR_ETYPE_NOTSUPP.

    One common cause of this is older devices that are requesting DES encrypted tickets. By default, DES encryption is disabled in Windows 7 and Windows Server 2008 R2. Ideally, you should update those devices or Kerberos clients to support the newer encryption algorithms. If they cannot be upgraded or replaced, then you can enable DES through group policy. For a good way to find these devices, I recommend reading Hunting down DES in order to securely deploy Kerberos by Ned Pyle.

    Another common cause of this is when a device requests an AES encrypted tickets before you raise the functional level of the domain to 2008 or higher. This does not typically occur on Windows clients as they request the legacy algorithms in addition to AES. This scenario is more likely to occur on Unix/Linux systems where an administrator specifies a single algorithm in the krb5.conf file. In this case, raise the functional level of the domain or configure the client to utilize another algorithm, like RC4-HMAC.

    If the client is requesting an algorithm that the domain controller should support, but is still returning the error, try resetting the password on the account and wait for replication to converge. Resetting the password regenerates the hashes stored in the directory.

    Note: Domain controllers do not store the password of the user. Instead, they store various hashes of the password using various algorithms.