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

Fallback NTLM Auth for Non-Domain Users

Krowten
I setup an ASG today as a pilot using AD SSO for authentication.  For the most part, this works fantastically.  I'm moving off a Squid proxy and I was supplying the IE settings via Group Policy and a proxy pac file.  So I just moved the pac file over to the ASG and changed my group policy and for 95% of the machines, this is working great.  But I have one issue:

Users that are using a laptop or other non-domain member machines

For these users, I put in the path to the PAC file, and I'm supplying the FQDN of the proxy, which is in the DNS Zone that is controlled by AD.  These users get a pop-up dialog, which I'm assuming is a fallback to NTLM AUTH.  But no matter what these users put in the box, the auth fails.  I cannot get the non-domain member machines to auth.  I see this in the proxy log:

2010:05:20-13:45:59 astaro01 httpproxy[6619]: [0xaf0803e8] auth_adir_auth_crap_callback (auth_adir.c:875) Authorization denied (NT_STATUS_PIPE_DISCONNECTED)
2010:05:20-13:45:59 astaro01 httpproxy[6619]: [0xaf0803e8] auth_adir_auth_crap_callback (auth_adir.c:875) Authorization denied (NT_STATUS_PIPE_DISCONNECTED)
2010:05:20-13:46:09 astaro01 httpproxy[6619]: [0xaf0803e8] auth_adir_auth_crap_callback (auth_adir.c:875) Authorization denied (NT_STATUS_PIPE_DISCONNECTED)
2010:05:20-13:46:11 astaro01 httpproxy[6619]: [0xaf0803e8] auth_adir_auth_crap_callback (auth_adir.c:875) Authorization denied (NT_STATUS_PIPE_DISCONNECTED)
2010:05:20-13:46:14 astaro01 httpproxy[6619]: [0xaf0803e8] auth_adir_auth_crap_callback (auth_adir.c:875) Authorization denied (NT_STATUS_PIPE_DISCONNECTED)
 

Again, the XP machines with IE8 that are domain members work flawlessly.  All the domain controllers are Windows 2008 R2.  I did find a few machines with XP and IE6 and these don't work either.  They fall back to NTLM and present the dialog.  Even though these machines are domain members, no matter what I put in the dialog box, I get the above errors in the log.


So, what is the trick here?  I need to be able to support these occasional roaming users, but I want to continue to give the majority users the benefit of the Kerberos based SSO.  

I did see some other references to this errors, but didn't see an exactly answer.

Thanks.

Matt


This thread was automatically locked due to age.
Parents
  • 0
    could you please post the PAC file configuration
    there is another way to do this (for non domain members), create a proxy profile and put their IP addresses and choose Standard mode
    as for IE6 did you try to put the IP address of Astaro instead of the FQDN?
Reply
  • 0
    could you please post the PAC file configuration
    there is another way to do this (for non domain members), create a proxy profile and put their IP addresses and choose Standard mode
    as for IE6 did you try to put the IP address of Astaro instead of the FQDN?
Children
  • 0 in reply to techuser
    Here is the pac file:

    function FindProxyForURL(url, host)
      {
            if (isPlainHostName(host) || isInNet(host,"10.0.0.0","255.255.255.0") ||  localHostOrDomainIs (host,"canon.blah.com") || isInNet(host,"127.0.0.1","255.255.255.255") || localHostOrDomainIs (host,"www.blah.net") || localHostOrDomainIs (host, "www.blah.com") || localHostOrDomainIs (host, "extranet.blah.com") || localHostOrDomainIs (host, "ids1.blah.com"))
                    return "DIRECT";
            else
                    return "PROXY astaro01.blah.com:8080";
      }


    I just removed the domain names from the post above.

    It turns out this is a known bug/issue when all the DC's are Windows 2008 R2.  Apparently, it is fixed in the 8.0 beta.

    I did not try just an IP address.  For now, I pushed out an IE8 upgrade to most of the machines that are domain members.

    Yes, I could make another policy per IP set to standard mode, but then I wouldn't have user login info plus with DHCP, I'm not always sure which address (although I could statically assign them in DHCP).

    Another option is to put a Windows 2003 DC back into this environment and point the ASG there.  Apparently that would work too.

    I do have an eDirectory tree syncing with AD.  I wonder if there is some way I can say if Kerberos fails, fall back to eDirectory based auth?

    Matt