| Author | Messages | |
rmscheck
Posts:245
 | | 08/28/2010 1:09 PM |
| Folks..
What are some ways you folks assure some level or redundancy for those
poor applications that use LDAP Auth but only all you to point to one
server.. I realize AD allows for severless binds, or better apps
utilize DNS for DC locator, but it appears we run a ton of little apps
here that get classified at 'critical' when you have a weak link in
its auth config like so.. (heck I imagine these apps are doing simple
binds and passing creds in cleartext, but thats another issue!)
CNAMES?
Load balanced virtual names?
What works?
Thanks
-Rand
| | | |
| AlLilianstrom
Posts:39
| | 08/28/2010 2:25 PM |
|
Rand Salazar wrote:
> Folks..
>
> What are some ways you folks assure some level or redundancy for those
> poor applications that use LDAP Auth but only all you to point to one
> server.. I realize AD allows for severless binds, or better apps
> utilize DNS for DC locator, but it appears we run a ton of little apps
> here that get classified at 'critical' when you have a weak link in
> its auth config like so.. (heck I imagine these apps are doing simple
> binds and passing creds in cleartext, but thats another issue!)
>
> CNAMES?
> Load balanced virtual names?
>
> What works?
>
> Thanks
> -Rand
>
Most of the LDAP aware apps we have can use the forest DNS name in their
configuration and handle DC outages quite well. The only one that comes
to mind that doesn't is Oracles OID. It needs a "connector" defined to
each DC and then a consultant had to write a ping based script to
rewrite the config file if a DC went offline and it was using that DC
for auth. This means that, for that app, auth could fail for up to 2
minutes while it switched over. I suppose I could put the DCs behind a
NLB but it's not worth the work for one app. We work with everyone who
us using AD for LDAP auth to ensure they are using LDAP over SSL.
al
Al Lilianstrom
lilstrom@fnal.gov
| | | |
| listmail
Posts:822
| | 08/28/2010 2:41 PM |
| Serverless binds actually are using the DC Locator service that relies on
DNS, so basically you have apps that have the ability to use DNS properly
for finding DCs and those that don't. I have seen people write their own DC
Locator service for their apps, yes, even on UNIX. The apps either have it
embedded in them or there is a script that sits and watches for changes and
updates the config of the stupid app as necessary.
You can also use CNAMES but then you end up having to create CNAMES by site
or other divisions that the apps want and having to manage all of it which
is RIDICULOUS. The DNS entries are already out there, use them. That would
be like buying a car, but someone doesn't like how the wheels roll so
instead force you to trailer it everywhere just for them where everyone else
is happy just to drive in it normally.
I have seen load balancers as well but have heard sporadic issues with kerb
auth though that likely isn't an issue here as the apps probably aren't
using secure binds anyway.
Other than that, I have seen people doing the same trick with LDAP auth as
we used to use with SAMBA. When you had SAMBA that needed to be pointed at a
specific DC, you could instead point it at a member server and the member
server was smart enough to go find the DC to perform the auth. Then let the
people running SAMBA support their member server. If it was part of the
domain, you were good and the AD people didn't care any more about it unless
someone doing the SAMBA did something stupid with their config and blew up
WINS.
So to do that same thing with LDAP auth, you set up an ADAM instance and
create userproxy objects in it and the apps auth to those userproxy objects
which tells ADAM in the backend to go look for the nearest DC that is
functioning. The fun thing is you can force it so that only SSL connections
will work for this which you can't do in AD to my knowledge (why not I don't
know).
joe
--
O'Reilly Active Directory Fourth Edition -
http://www.joeware.net/win/ad4e.htm
Blog: http://blog.joeware.net
-----Original Message-----
From: activedir-owner@mail.activedir.org
[mailto:activedir-owner@mail.activedir.org] On Behalf Of Rand Salazar
Sent: Saturday, August 28, 2010 8:07 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Poor poor LDAP Auth
Folks..
What are some ways you folks assure some level or redundancy for those
poor applications that use LDAP Auth but only all you to point to one
server.. I realize AD allows for severless binds, or better apps
utilize DNS for DC locator, but it appears we run a ton of little apps
here that get classified at 'critical' when you have a weak link in
its auth config like so.. (heck I imagine these apps are doing simple
binds and passing creds in cleartext, but thats another issue!)
CNAMES?
Load balanced virtual names?
What works?
Thanks
-Rand
| | | |
| jamesawells
Posts:79
| | 08/28/2010 4:10 PM |
| In larger environments with dumb but critical apps, I've seen good success with load balancing LDAP and secure LDAP. Kerberos certainly won't work, but I've not seen any other problems; Microsoft KBs indicate to me that there is lukewarm support for this, though.
SSL will certainly need a subject alt name for the load-balanced address, but there are several ways to tackle that requirement.
I've also seen CNAMEs point to specific DCs, sometimes with monitoring solutions to run a DNSCMD and change the CNAME if that DC is offline...but that will usually still result in some downtime for apps pointed to it.
--James
-----Original Message-----
From: Al Lilianstrom <lilstrom@fnal.gov>
Sent: August 28, 2010 9:23 AM
To: activedir@mail.activedir.org <activedir@mail.activedir.org>
Subject: Re: [ActiveDir] Poor poor LDAP Auth
Rand Salazar wrote:
> Folks..
>
> What are some ways you folks assure some level or redundancy for those
> poor applications that use LDAP Auth but only all you to point to one
> server.. I realize AD allows for severless binds, or better apps
> utilize DNS for DC locator, but it appears we run a ton of little apps
> here that get classified at 'critical' when you have a weak link in
> its auth config like so.. (heck I imagine these apps are doing simple
> binds and passing creds in cleartext, but thats another issue!)
>
> CNAMES?
> Load balanced virtual names?
>
> What works?
>
> Thanks
> -Rand
>
Most of the LDAP aware apps we have can use the forest DNS name in their
configuration and handle DC outages quite well. The only one that comes
to mind that doesn't is Oracles OID. It needs a "connector" defined to
each DC and then a consultant had to write a ping based script to
rewrite the config file if a DC went offline and it was using that DC
for auth. This means that, for that app, auth could fail for up to 2
minutes while it switched over. I suppose I could put the DCs behind a
NLB but it's not worth the work for one app. We work with everyone who
us using AD for LDAP auth to ensure they are using LDAP over SSL.
al
Al Lilianstrom
lilstrom@fnal.gov
| | | |
| Ravi.Sabharanjak@blackrock.com
Posts:98
| | 08/30/2010 5:18 PM |
| We tried using the forest name in the app configurations, but ran into 2
problems -
- the way our network is subnetted, the client gets connected to
non-optimal, remote domain controllers.
- Random, hard to pinpoint errors if one or more domain controllers is
down for maintenance or has been decommissioned without removing it's
DNS registrations for the forest name.
We've settled on using a load balanced name that gets us more control on
which DC's are used and also allows us to scale up without requiring app
config changes.
Regards,
-Ravi
-----Original Message-----
From: activedir-owner@mail.activedir.org
[mailto:activedir-owner@mail.activedir.org] On Behalf Of Al Lilianstrom
Sent: Saturday, August 28, 2010 6:23 AM
To: activedir@mail.activedir.org
Subject: Re: [ActiveDir] Poor poor LDAP Auth
Rand Salazar wrote:
> Folks..
>
> What are some ways you folks assure some level or redundancy for those
> poor applications that use LDAP Auth but only all you to point to one
> server.. I realize AD allows for severless binds, or better apps
> utilize DNS for DC locator, but it appears we run a ton of little apps
> here that get classified at 'critical' when you have a weak link in
> its auth config like so.. (heck I imagine these apps are doing simple
> binds and passing creds in cleartext, but thats another issue!)
>
> CNAMES?
> Load balanced virtual names?
>
> What works?
>
> Thanks
> -Rand
>
Most of the LDAP aware apps we have can use the forest DNS name in their
configuration and handle DC outages quite well. The only one that comes
to mind that doesn't is Oracles OID. It needs a "connector" defined to
each DC and then a consultant had to write a ping based script to
rewrite the config file if a DC went offline and it was using that DC
for auth. This means that, for that app, auth could fail for up to 2
minutes while it switched over. I suppose I could put the DCs behind a
NLB but it's not worth the work for one app. We work with everyone who
us using AD for LDAP auth to ensure they are using LDAP over SSL.
al
Al Lilianstrom
lilstrom@fnal.gov
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE PRIVILEGED. If this message was misdirected, BlackRock, Inc. and its subsidiaries, ("BlackRock") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this e-mail message are the author's own and may not reflect the views and opinions of BlackRock, unless the author is authorized by BlackRock to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by BlackRock. Although BlackRock operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.
| | | |
| jserban
Posts:18
| | 08/31/2010 6:32 PM |
| As Ravi noted, the forest name approach can lead to less than optimal results. If you have a single datacenter, you can mitigate this with SRV record priorities to guide non-site aware apps to a preferred set of servers.
Where the forest name approach really falls down is when you have multiple datacenters and want to provide a per-datacenter alias for application configuration. I have recently implemented a load balanced alias to name abstraction and some fault tolerance to LDAP applications. As someone who is mid way through the upgrade to Windows 2008 R2, name abstraction is something that would have made the domain upgrade go more smoothly. Any change to the domain infrastructure (upgrade/retirement) needs to be preceded with an investigation to determine what is pointing at the legacy domain controller.
If you don't have a load balancer available, you could use a CNAME record in DNS for name abstraction. You could also use round robin DNS for some rudimentary fault tolerance in that 50% of your LDAP lookups would succeed if one of the two round robin nodes was down.
Thanks,
John
-----Original Message-----
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Sabharanjak, Ravi
Sent: Monday, August 30, 2010 12:17 PM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Poor poor LDAP Auth
We tried using the forest name in the app configurations, but ran into 2
problems -
- the way our network is subnetted, the client gets connected to
non-optimal, remote domain controllers.
- Random, hard to pinpoint errors if one or more domain controllers is
down for maintenance or has been decommissioned without removing it's
DNS registrations for the forest name.
We've settled on using a load balanced name that gets us more control on
which DC's are used and also allows us to scale up without requiring app
config changes.
Regards,
-Ravi
-----Original Message-----
From: activedir-owner@mail.activedir.org
[mailto:activedir-owner@mail.activedir.org] On Behalf Of Al Lilianstrom
Sent: Saturday, August 28, 2010 6:23 AM
To: activedir@mail.activedir.org
Subject: Re: [ActiveDir] Poor poor LDAP Auth
Rand Salazar wrote:
> Folks..
>
> What are some ways you folks assure some level or redundancy for those
> poor applications that use LDAP Auth but only all you to point to one
> server.. I realize AD allows for severless binds, or better apps
> utilize DNS for DC locator, but it appears we run a ton of little apps
> here that get classified at 'critical' when you have a weak link in
> its auth config like so.. (heck I imagine these apps are doing simple
> binds and passing creds in cleartext, but thats another issue!)
>
> CNAMES?
> Load balanced virtual names?
>
> What works?
>
> Thanks
> -Rand
>
Most of the LDAP aware apps we have can use the forest DNS name in their
configuration and handle DC outages quite well. The only one that comes
to mind that doesn't is Oracles OID. It needs a "connector" defined to
each DC and then a consultant had to write a ping based script to
rewrite the config file if a DC went offline and it was using that DC
for auth. This means that, for that app, auth could fail for up to 2
minutes while it switched over. I suppose I could put the DCs behind a
NLB but it's not worth the work for one app. We work with everyone who
us using AD for LDAP auth to ensure they are using LDAP over SSL.
al
Al Lilianstrom
lilstrom@fnal.gov
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE PRIVILEGED. If this message was misdirected, BlackRock, Inc. and its subsidiaries, ("BlackRock") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this e-mail message are the author's own and may not reflect the views and opinions of BlackRock, unless the author is authorized by BlackRock to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by BlackRock. Although BlackRock operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.
-----------------------------------------
This email transmission and any accompanying attachments may
contain CSX privileged and confidential information intended only
for the use of the intended addressee. Any dissemination,
distribution, copying or action taken in reliance on the contents
of this email by anyone other than the intended recipient is
strictly prohibited. If you have received this email in error
please immediately delete it and notify sender at the above CSX
email address. Sender and CSX accept no liability for any damage
caused directly or indirectly by receipt of this email.
| | | |
| kbatkbslpcom
Posts:194
| | 08/31/2010 7:56 PM |
| And if your organization can't afford a true load balanced solution -
the CNAME solution (with a short TTL of the A record it points to - or
just an additional 'generic' A record) could be scripted for automatic
failover.
The script would check port 389 (default - or 3268, depending upon if
you need a GC) on the DC that the A/CNAME record points to - if it
becomes unavailable (for X amount of time) - de-register and re-register
in DNS an alternate DC for that name (then, of course, the script has to
check that DC to ensure it is available, etc).
It is some amount of work (depending upon ones level of scripting
skills) - and would give, within a 'set' amount of time some level of
automatic failover (how much time depends upon how often the script
runs, how quickly DNS changes replicate in your org, TTL of the record,
etc).
I had started to go this route...before the load balancer solution was
implemented some years ago (checking port 389, TTL=0)...and recently
implemented a "sticky" function - so that the load balancer will always
pass out the same DC IP address to any given client (we have 6 DC's per
domain behind each load balanced name - and all of those DC's are also
GC's).
-----Original Message-----
From: activedir-owner@mail.activedir.org
[mailto:activedir-owner@mail.activedir.org] On Behalf Of Serban, John
Sent: Tuesday, August 31, 2010 1:31 PM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Poor poor LDAP Auth
As Ravi noted, the forest name approach can lead to less than optimal
results. If you have a single datacenter, you can mitigate this with
SRV record priorities to guide non-site aware apps to a preferred set of
servers.
Where the forest name approach really falls down is when you have
multiple datacenters and want to provide a per-datacenter alias for
application configuration. I have recently implemented a load balanced
alias to name abstraction and some fault tolerance to LDAP applications.
As someone who is mid way through the upgrade to Windows 2008 R2, name
abstraction is something that would have made the domain upgrade go more
smoothly. Any change to the domain infrastructure (upgrade/retirement)
needs to be preceded with an investigation to determine what is pointing
at the legacy domain controller.
If you don't have a load balancer available, you could use a CNAME
record in DNS for name abstraction. You could also use round robin DNS
for some rudimentary fault tolerance in that 50% of your LDAP lookups
would succeed if one of the two round robin nodes was down.
Thanks,
John
-----Original Message-----
From: activedir-owner@mail.activedir.org
[mailto:activedir-owner@mail.activedir.org] On Behalf Of Sabharanjak,
Ravi
Sent: Monday, August 30, 2010 12:17 PM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Poor poor LDAP Auth
We tried using the forest name in the app configurations, but ran into 2
problems -
- the way our network is subnetted, the client gets connected to
non-optimal, remote domain controllers.
- Random, hard to pinpoint errors if one or more domain controllers is
down for maintenance or has been decommissioned without removing it's
DNS registrations for the forest name.
We've settled on using a load balanced name that gets us more control on
which DC's are used and also allows us to scale up without requiring app
config changes.
Regards,
-Ravi
-----Original Message-----
From: activedir-owner@mail.activedir.org
[mailto:activedir-owner@mail.activedir.org] On Behalf Of Al Lilianstrom
Sent: Saturday, August 28, 2010 6:23 AM
To: activedir@mail.activedir.org
Subject: Re: [ActiveDir] Poor poor LDAP Auth
Rand Salazar wrote:
> Folks..
>
> What are some ways you folks assure some level or redundancy for those
> poor applications that use LDAP Auth but only all you to point to one
> server.. I realize AD allows for severless binds, or better apps
> utilize DNS for DC locator, but it appears we run a ton of little apps
> here that get classified at 'critical' when you have a weak link in
> its auth config like so.. (heck I imagine these apps are doing simple
> binds and passing creds in cleartext, but thats another issue!)
>
> CNAMES?
> Load balanced virtual names?
>
> What works?
>
> Thanks
> -Rand
>
Most of the LDAP aware apps we have can use the forest DNS name in their
configuration and handle DC outages quite well. The only one that comes
to mind that doesn't is Oracles OID. It needs a "connector" defined to
each DC and then a consultant had to write a ping based script to
rewrite the config file if a DC went offline and it was using that DC
for auth. This means that, for that app, auth could fail for up to 2
minutes while it switched over. I suppose I could put the DCs behind a
NLB but it's not worth the work for one app. We work with everyone who
us using AD for LDAP auth to ensure they are using LDAP over SSL.
al
Al Lilianstrom
lilstrom@fnal.gov
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY
BE PRIVILEGED. If this message was misdirected, BlackRock, Inc. and its
subsidiaries, ("BlackRock") does not waive any confidentiality or
privilege. If you are not the intended recipient, please notify us
immediately and destroy the message without disclosing its contents to
anyone. Any distribution, use or copying of this e-mail or the
information it contains by other than an intended recipient is
unauthorized. The views and opinions expressed in this e-mail message
are the author's own and may not reflect the views and opinions of
BlackRock, unless the author is authorized by BlackRock to express such
views or opinions on its behalf. All email sent to or from this address
is subject to electronic storage and review by BlackRock. Although
BlackRock operates anti-virus programs, it does not accept
responsibility for any damage whatsoever caused by viruses being passed.
-----------------------------------------
This email transmission and any accompanying attachments may contain CSX
privileged and confidential information intended only for the use of the
intended addressee. Any dissemination, distribution, copying or action
taken in reliance on the contents of this email by anyone other than the
intended recipient is strictly prohibited. If you have received this
email in error please immediately delete it and notify sender at the
above CSX email address. Sender and CSX accept no liability for any
damage caused directly or indirectly by receipt of this email.
| | | |
| Ravi.Sabharanjak@blackrock.com
Posts:98
| | 08/31/2010 8:26 PM |
| Other factors to consider -
- Some apps look up a DNS name only at startup. These typically need a
restart for a DNS cname change to take effect, regardless of the ttl on
the name. Mostly these are Java apps.
- If you are running apps on UNIX, the nscd will cache all DNS records
for the same time. It does not honor TTL's.
Below is some research done on both the above by a former colleague -
Note: This is a bit old, so things may have changed
-Ravi
There are 2 known cases where DNS-based failover will fail - Java
applications and applications running on Unix servers.
Java
Java (running on all platforms) has a configuration parameter that
controls how long the JVM (Java Virtual Machine) will cache successful
DNS lookups. This overrides any Operating System settings as it's
managed by the JVM directly. The default value for
networkaddress.cache.ttl for all Java versions prior to the current (6)
was -1, or Cache Forever. This means that any Java application will need
to be restarted after a DNS change is made. Under Java 6, the default
is changed (to "implementation dependent") when not running under the
Security Manager.
The solution is to force the JVM to stop caching DNS values, or to cache
them for a limited time (30 seconds). There are a number of ways of
achieving this, and while it may not be necessary for applications
running under Java 6, there is no disadvantage to applying it across all
Java deployments.
Option 1 - make a code change
Adding the following line to the source-code and recompiling:
java.security.Security.setProperty("networkaddress.cache.ttl" ,
"30");
While this is recommended for any code that will be deployed outside of
the firm where the JVM cannot be controlled, it is unrealistic to expect
this to happen for already running software.
Option 2 - add a command-line option
Existing startup scripts can be updated to include the following on the
Java command-line:
-Dsun.net.inetaddr.ttl=30
This has the advantage of not requiring any code changes, but every
startup script will need to be updated
Option 3 - update the java.security file
The following line can be added to $JAVA_HOME/lib/security/java.security
(or %JAVA_HOME%\lib\security\java.security under Windows):
networkaddress.cache.ttl=60
This also does not require any code change, but there is the effort
involved of creating and deploying a new package or copying this file
across all hosts that use Java.
Option 3 is probably the best short-term option as it requires no
involvement from the application developers or deployment team.
Unix Servers
Unix servers within the firm use nscd, the Name Service Cache Daemon.
This is a requirement to allow Kerberos authentication to take place.
The problem is that nscd will cache DNS values in violation of the TTL
values and thus defeat any DNS-based failover.
Option 1 - replace nscd with simple LDAP bindings
Deploying the already tested authentication system of simple LDAP
binding will eliminate the need to use nscd. This will allow nscd to be
removed from all Unix servers and allow correct DNS-based failover.
{However, there is an overhead associated with this because of
eliminating the cache}
Option 2 - update the nscd.conf file
By changing certain values in the nscd configuration file
(/etc/nscd.conf), it is possible to disable DNS caching (or set it to an
appropriately limited time). The following are the relevant values:
enable-cache hosts no
positive-time-to-live hosts 60
persistent hosts no
Option 1 is the better choice, but until it gets deployed, option 2 is
an easy system-wide change.
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE PRIVILEGED. If this message was misdirected, BlackRock, Inc. and its subsidiaries, ("BlackRock") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this e-mail message are the author's own and may not reflect the views and opinions of BlackRock, unless the author is authorized by BlackRock to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by BlackRock. Although BlackRock operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.
| | | |
|
|