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

Problems with server 2008 R2

GORDONSUK
Have just rcently changed to Server 2008 R2 and now cannot get SSO with Active Directory to work. Have successfully joined the domain as per the same setup we did with 2003. Users are identified on prefetch, however on the HTTP access log we get the following,

2010:01:20-10:11:48 gateway httpproxy[5594]: [ 0x88200a8] auth_adir_auth_crap_callback (auth_adir.c:875) Authorization denied (NT_STATUS_PIPE_DISCONNECTED)
2010:01:20-10:11:48 gateway httpproxy[5594]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="GET" srcip="192.168.0.213" user="paul" statuscode="407" cached="0" profile="REF_DefaultHTTPProfile (Default Proxy)" filteraction=" ()" size="2195" time="0 ms" request="0x88200a8" url="www.astaro.com/favicon.ico" exceptions="" error="" 

And end users are always prompted for username and password which is not accepted. 

Any ideas?


This thread was automatically locked due to age.
Parents
  • 0
    Hello,

    can you told me if you insert the porxy settings with ip-address or with fqdn.
    Because ip-address in the client proxy setting don't work. The problem is that astaro must speak kerberos with the ad server, not NTLM and when you use the IP-Address you use NTLM. So this is wrong, please insert the FQDN to the Proxy Client Settings

    Regards,
    Steffen
Reply
  • 0
    Hello,

    can you told me if you insert the porxy settings with ip-address or with fqdn.
    Because ip-address in the client proxy setting don't work. The problem is that astaro must speak kerberos with the ad server, not NTLM and when you use the IP-Address you use NTLM. So this is wrong, please insert the FQDN to the Proxy Client Settings

    Regards,
    Steffen
Children
  • 0 in reply to sunland_01
    Thanks for the replies. Have come up with a temp solution. We have brought a 2003 server back online and synced it to the new server. The users are now pulled from there for authorisation. Works fine!!
  • 0 in reply to sunland_01
    I can confirm this is the right solution. We are using 2008 R2 domain controller, and forest and domain all in R2 level (2003 is not an option). When using IP as proxy address, it will fail to authentication, and pops up login screen. With FQDN, everything works fine as expected. Thanks!

    Hello,

    can you told me if you insert the porxy settings with ip-address or with fqdn.
    Because ip-address in the client proxy setting don't work. The problem is that astaro must speak kerberos with the ad server, not NTLM and when you use the IP-Address you use NTLM. So this is wrong, please insert the FQDN to the Proxy Client Settings

    Regards,
    Steffen
  • 0 in reply to speed
    Well either way it works and a solution was needed quickly.
  • 0 in reply to GORDONSUK
    Hello there

    i have the same problem: we changed to Win 2008 R2 and have no more 2003 Servers in our network. we use a pac-file for the proxy config. if i use the fqdn of asg this works fine for ie8 and other ie versions. but firefox can not handle this and can not find the proxy-server.

    anyone got an idea?

    best regards
    mike
  • 0 in reply to ionee
    As Jack Daniel said:

    When using 2008 R2 (honestly, I configure all my customers this way anyway, regardless of whether they are running a 2003 DC or 2008 DC, NTLM is a weaker form of authentication compared to Kerberos), use the FQDN (full dns host name... astaro.yourdomain.local, for example) in the Proxy configuration section of IE (this can be pushed out via Group Policy).  If you do this, the Browser will use Kerberos to authenticate.  If you use the IP address, NTLM is used.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.