Ldap authentication failing after backup DC taken offline

For what it's worth, we have multiple endpoints and SSO is configured for https for login only for our internal portal users.

 Did you recycle/restart your system after the backup DC went down?

Have you reviewed your SSOP service to make sure it's pointing to the primary DC?

We did not restart server and ssoconfig -c did not show any pointers to backup DC.
Could it be hiding in Adam?

We encountered similar issues when we turned off a backup DC. Although we were bound to a different DC, Lawson was still impacted. We did reboot our Lawson servers after the DC shutdown and that seemed to provide some relief, but not in all cases. We found that several tecniques would make the authentication work but they weren't reliable. These included: logging off and back on the network, clearing browser cache, closing and opening a new browser window. Even if a user was successful in authenticating, if he logged out and tried to log back on in the same session, it could fail. But, if he opened up a new browser window, it would work. And authenticating for MS Addins was an even stranger routine.

Consequently, I opened a LIS case. Since we really wanted to retire this particular server, the resolution was to bring the DC back online, then demote it from its DC role and remove it from the network. Upon doing this, and rebooting my Lawson servers, all authentications returned to normal.

Stupid question: your backup DC would not happen to be the only GC right?

Not sure if this is even possible, but could the "Lawson" ldap RM data only be stored on the one DC but not the other? Not sure what you mean by GC.

Sorry, my networking guys tell me the the primary is Global Catalog (GC).

Did you check to see if your network settings > TCPIP > DNS is not pointing to the backup DC? Check them all for your Portal server, App server, LDAP server, database server. They should only be pointing to your other DCs with exception of the backup DC.

For example, if your LDAP server is using your backup DC as DNS, the second you shut off backupDC, LDAP goes offline regardless of where your LDAPBIND is point to.

Yes. We originally had both primary and secondary DC's defined in TCPIP setup in the correct order and removed the secondary altogether to no avail - Lawson was still going out to the backup DC. We ran a Wireshark trace and the log shows a sucessful user CN lookup to the primary DC and immediately after that our lawson server is issuing another lookup to the backup DC.

Are you using a load balancer?

No load balancer that I am aware of. We were able to resolve this with the help of Lawson and the issue seems to be related to stale or cached DNS information. We ran Wireshark traces and found that after the initial call from Lawson to the pimary DC was made to verify a users credentials, information was returned to Lawson informing it that a secondary AD store exists and Lawson than made a call to to the backup DC (although it didn't need any additional information). To resolve the issue we took the following steps: 1) Moved the backup DC to new IP address. 2) Deleted all DNS entries on both DC's related to backup DC's old IP address (foward lookup, reverse, forest entries, etc.) 3) Changed Lawson ssoconfig to call primary DC by IP rather than name. 4) Flush DNS cache on both DC's and the Lawson server 5) Reboot Lawson server (this step was key - without reboot there were still some references hiding to backup DC's old address). We also learned that although the backup DC serves as a failover for Windows authentication that LSF 9.00X can only point to 1 DC so if we lost our primary DC a manual change would be required to get Lawson authenticating again. According to Lawson support this limitation was addressed in LSF 9.01X and more than one DC and be defined in sso.

Posted By Joe O'Toole on 03/16/2010 02:39 PM
No load balancer that I am aware of. We were able to resolve this with the help of Lawson and the issue seems to be related to stale or cached DNS information. We ran Wireshark traces and found that after the initial call from Lawson to the pimary DC was made to verify a users credentials, information was returned to Lawson informing it that a secondary AD store exists and Lawson than made a call to to the backup DC (although it didn't need any additional information). To resolve the issue we took the following steps: 1) Moved the backup DC to new IP address. 2) Deleted all DNS entries on both DC's related to backup DC's old IP address (foward lookup, reverse, forest entries, etc.) 3) Changed Lawson ssoconfig to call primary DC by IP rather than name. 4) Flush DNS cache on both DC's and the Lawson server 5) Reboot Lawson server (this step was key - without reboot there were still some references hiding to backup DC's old address). We also learned that although the backup DC serves as a failover for Windows authentication that LSF 9.00X can only point to 1 DC so if we lost our primary DC a manual change would be required to get Lawson authenticating again. According to Lawson support this limitation was addressed in LSF 9.01X and more than one DC and be defined in sso.

Anyone know how to define multiple DC in sso in 9.0.1.X? I looked everywhere and can't find it.

THE GSC made it sound like the option was available in ssoconfig, but being on 9.004 I can't tell. If you are not seeing an option to add an additional DC address in ssoconfig, you might need to dump your sso config file (sso_prod.xml in my case) then add the extra DC entry and reimport. You can either reload manually via ssoconfig menu or use sso_config -l to load via script. Make sure you back up your original sso config file, if the revised import has some problem and you don't have the original to fix it you could be in a bad spot. You might want to check with the GSC or see if there is a KB article before attempting this.