 |
 |
We had some nasty issues when our domain was being upgraded. At one point we had a mixed 2003 and 2008 domain. This caused issues when authenticating via Kerberos or LDAP depending on which AD server the auth attempt got routed to and whether the user account had changed the password recently we would get login errors. It all went away when all our domain got upgraded to 2008, our interim work around was to point our auth at an old 2003 AD server until the domain upgrade was complete. I think the AD does not like being in a mixed version number domain and messes up the ldap and kerb authentication. Certainly the fact that the problem persisted regardless of protocol (ldap or kerb) or client library (shib ldap, shib kerb, mod_auth_kerb, kinit on command line) suggests it was a problem at the server end. >-----Original Message----- >From: Discussion list for Shibboleth developments [mailto:JISC- >[log in to unmask]] On Behalf Of Heather Peake >Sent: 07 December 2010 12:58 >To: [log in to unmask] >Subject: AD on Windows Server 2008 R2 - any issues? > >Hi >We have a version 2 IDP up and running on a Windows server with Apache >using CAS and authenticating against Active Directory on a Windows >Server 2003. >They are migrating AD to a Windows server 2008 R2. >Currently the AD is the same on both types of server. I just tried >switching our authentication from pointing the 2003 server to the 2008 >server and now we get the HTTP Status 404 error telling me Apache Tomcat >is not available. >For the time being I've switched it back to the 2003 server, but long >term this is in demise. > >Is there something significantly different between authenticating to >2003 and 2008 R2. Can anybody point me at appropriate info that I've >clearly missed? I will admit to being not very good with Shibboleth and >thus fairly hopeless at trouble shooting it. >Today's foray into the unknown world of server 2008 was because we were >getting reports from the Gale group resources saying we were not >releasing attributes which made no sense as we have made no changes it >was just chugging a long happily. We had noticed a clock issue this >morning and to be honest I was hoping that was it, but thought we would >try the new AD server because it needed trying. > >Thanks.