AD Failover

Hi Thomas,

There may be a little confusion in the primary and secondary terms.  In short setting one vs the other doesn't really mater in the sense that ALL my requests would go to the primary and then fail over to the secondary.. It's more like bind will have 2 servers to choose from and its going to default to X first.  it may also be possible the secondary responds faster than the primary.

The warning email you got is most likely bind reporting back "some" issue with the server.. perhaps it lost contact, or no route or it was slow etc..  could actually be a pluthra of things or it could also be the primary failed to respond when it attempts to re-sync to it..  happens every few hrs.

a common issue that may happen is if your deployed in explicit mode and under default authentication have "authenticate every request"  definitely not recommended and may cause issues .. think of it in cnn.com terms.. pulling dynamic content from 100's of servers could result in 100's of authentication requests. 

Hi Red_Warrior

Thank you for your reply. We thought it would work like active / passive. But the way like you explained it, works fine too.

We will check if we get more emails regarding "primary failed".

It looks like we use this common issue, our web appliance is set to "authenticate every request". Do we get any problem if we disable this?

greetings

Hi Red_Warrior

Thank you for your reply. We thought it would work like active / passive. But the way like you explained it, works fine too.

We will check if we get more emails regarding "primary failed".

It looks like we use this common issue, our web appliance is set to "authenticate every request". Do we get any problem if we disable this?

greetings

Hi Thomas,

In general the only time you would use authenticate all requests is if you had virtual/thin clients using a terminal server.  This causes every packet to be stamped with the user info .. and the same ip address.  This makes it impossible for the appliance to cache credentials.  Even in this scenario its better to configure TS to generate internal ips for each client. 

When you enable SSO, the appliance will see the user and ip information.. It will authenticate the first request with ad and then cache a credential for 4m59s ..  this will ensure the appliance looks at the cached credential before asking ad for another auth request.  of course if a user change is detected or similar the next request would be authenticated as normal. 

This is far more efficient than hammering ad with requests.. sites like cnn may pull down 100+ requests to dynamically render the page.  hammering ad with all those requests is not necessary.

this will also reduce the number of false ad alerts that are generated.

Hi Red_Warrior

Thank you again for you explenation. Sorry for the late answer. We use thin clients that connect to a terminal server. 

greetings and thx again

No Problem at all,

In your case the best solution can be found here

https://cloudblogs.microsoft.com/enterprisemobility/2009/07/10/configuring-remote-desktop-ip-virtualization-part-1/

this will make the terminal server create virtual IP's for each user that is using a thin client in turn this will pass a unique IP down to the appliance.  This will allow you to us SSO credentials for your virtual users.

Authenticate every request can be problematic .. I would only use it as a last result..

currently the appliance sees this..

10.10.10.1  sally

10.10.10.1 bill

10.10.10.1 jim

because we need both the ip and username to do sso, its going to hammer your ad server with each individual request.. every time one fails or the ad server fails to respond, your going to get an error. 

when you enable the virtual ips:

10.10.10.1  sally

10.10.10.2 bill

10.10.10.3 jim

now we can cache 3 ips one for each and re-auth them every 4m59sec when they expire.. this will greatly reduce the overhead and chance of failures and still provide you with the best web experience. 

Cheers