Active Directory SSO Web Proxy problem

Could you please post your configuration so we can help you? Does this affect all users or just this user?

Hello,

Everything is working fine with 8.102, untill users cannot authenticate via SSO on Web proxy, the error in our browsers is "Authentication Failure", I check the ADServer test authentication on the Webamin, the user,AD groups is syncronizing well, I started to see this problem when some users we add in INTERNET USER AD group, and this AD group is allowed for internet in Web proxy Profile  with SSO, when i check the logs in the web proxy, the user is not existed, so it means the web proxy is not updating, but the user account is already existed in the astaro and it passed the test authentication. pls . help


Thanks in advance

Did you see the prefech log if any error displays?

Try to query groups for the users on:

Users>Authentication>Servers>Edit your server>put your base dn>put an user of the AD and password> And hit test, if a little pop up window display the group of the user every thing with the Asg and the AD it work's fine, so have to be on the proxy profile the problem meaby, try to delete the user with the issue and syncronize again.

Did you see the prefech log if any error displays?

Try to query groups for the users on:

Users>Authentication>Servers>Edit your server>put your base dn>put an user of the AD and password> And hit test, if a little pop up window display the group of the user every thing with the Asg and the AD it work's fine, so have to be on the proxy profile the problem meaby, try to delete the user with the issue and syncronize again.

Be aware; that tests using an LDAP query; that doesn't test if there is a passthrough NTLM problem; which is usually the source of these problems. To avoid that there are three key undocumented best practices:

1) Use your AD Controller as the only DNS resolver for the ASG; support will tell you not to use request routing. Use your AD Controller to forward requests to the upstream dns servers. It feels backwards but that's what MS AD is expecting. Don't fight it if you want it to work.

2) Set your proxy settings by IP ADDRESS not DnsNames; that forces it into NTLM mode which avoids all the Kerberos bugs, there are tons of kerberos bugs that like to crep in; clock drift being the least annoying.

3) make sure that the MAIN Astaro FQDN hostname is in your local AD Domain. The on screen instructions say to use a FQDN that is your public one; that is wrong if you want AD SSO. Example if you want to call your machine  "PROXY" and the AD Domain is "FOO.LOCAL" then you should set your Astaro FQDN Hostname to be "PROXY.FOO.LOCAL" and then join the AD domain as that name. If you haven't done that you need to delete your astaro from the domain; rename it; rejoin it; and then reboot it.


We have 50 units in separate AD domains and this was the only way to get consistent and reliable results everywhere....  REALLY looking forward to the native windows client coming in 8.2 because SSO has never been robust nor reliable.

Be aware; that tests using an LDAP query; that doesn't test if there is a passthrough NTLM problem; which is usually the source of these problems. To avoid that there are three key undocumented best practices:

1) Use your AD Controller as the only DNS resolver for the ASG; support will tell you not to use request routing. Use your AD Controller to forward requests to the upstream dns servers. It feels backwards but that's what MS AD is expecting. Don't fight it if you want it to work.

2) Set your proxy settings by IP ADDRESS not DnsNames; that forces it into NTLM mode which avoids all the Kerberos bugs, there are tons of kerberos bugs that like to crep in; clock drift being the least annoying.

3) make sure that the MAIN Astaro FQDN hostname is in your local AD Domain. The on screen instructions say to use a FQDN that is your public one; that is wrong if you want AD SSO. Example if you want to call your machine  "PROXY" and the AD Domain is "FOO.LOCAL" then you should set your Astaro FQDN Hostname to be "PROXY.FOO.LOCAL" and then join the AD domain as that name. If you haven't done that you need to delete your astaro from the domain; rename it; rejoin it; and then reboot it.


We have 50 units in separate AD domains and this was the only way to get consistent and reliable results everywhere....  REALLY looking forward to the native windows client coming in 8.2 because SSO has never been robust nor reliable.

Hi Ratz,

Thank's for you repply, that you have any experience with the bug in Webproxy with the change of users in the AD? I have an issue with this, I have two diferent profiles, one restricted and another a little bit less restricted, but when we change a user of group in the AD the change not work, we have to reset the webproxy with any change, and some times the change work's, cheers.

Ratz, I agree that you can make things work that way, but I think people setting up a new configuration will find it easier and more robust to configure as detailed in the KnowledgeBase article Configure HTTP/S Proxy with AD-SSO.

Your suggestion in 1) will work, but things at all my clients are configured as in DNS Best Practice, and that also works fine with AD-SSO.

Although NTLM often works, the most-reliable method with Windows servers is kerberos.  This is the method recommended in the document linked to above. 

Finally, unless your Astaros all are local, it can really complicate several other things if you use a hostname different from the FQDN that resolves to the public IP.  In general, our clients have a hostname of "mail.example.com", internal domain of "example.local" and after the Astaro has joined the domain, it shows up as "mail" in the AD.

RVasquezgt, after you made the group changes, did you 'Flush the authentication cache' on the 'Global' tab of 'Users >> Authentication'?  If not, I think you have to wait 15 minutes for a re-authorization to occur.

Cheers - Bob