Improve Active Directory utilisation and availability

  • 610 Views
  • Last Post 19 April 2012
Johnchristie11 posted this 15 April 2012

Hi all

I've been asked as part of my next years development review to identify
ways of improving the availability and utilisation of Active Directory
within our infrastructure.

Can anyone provide some ideas of what I could look at? Cost is obviously a
restriction but my initial thoughts are:

* Look at ADFS for partner organisations
* Use our IDM solution to provision accounts to all domains. At the moment
it just manages production
* Replace physical domain controllers with virtual servers. The hardware
are coming towards the end of their 3yr lifecycle and virtualisation could
be a cost effective.

Thanks

JC

Order By: Standard | Newest | Votes
slavickp posted this 17 April 2012

G'day -

This is a broad topic. I'd recommend splitting the problem area into
several strands:

1. Health and risk. Here you put items that will make sure your AD is
healthy, replicating, sites topology is optimal, errors in the event
logs addressed, and your response to critical situations with AD (from
object deletion to forest recovery) are documented and tested, etc;
2. Lifecycle of hardware and software. Here's your virtualisation effort
and implementation of newer version of Active Directory; and
3. Enablement and optimisation. This is where you start using features
of the software that you have - use of ADFS, DFSn and DFSr, Certificate
Services, smart cards, etc; better interaction with IDM can go here;
unified, fault tolerant LDAP farm for application integration can be
important.

It's hard to tell much without knowing specifics of your organisation.
Looks like you have several good ideas.

regards

Slav


On 16/04/2012 2:20 AM, John Christie wrote:
>
> Can anyone provide some ideas of what I could look at? Cost is
> obviously a restriction but my initial thoughts are:
> I've been asked as part of my next years development review to
> identify ways of improving the availability and utilisation of Active
> Directory within our infrastructure.
>
> * Look at ADFS for partner organisations
> * Use our IDM solution to provision accounts to all domains. At the
> moment it just manages production
> * Replace physical domain controllers with virtual servers. The
> hardware are coming towards the end of their 3yr lifecycle and
> virtualisation could be a cost effective.
>
>
>

show

kenhooveryaleedu posted this 17 April 2012

Under the "utilisation" category, I would work on improving the usefulness of your AD as an AuthN/AuthZ source for third-party applications.

In our case, this was both a technical change -- putting a F5 load balancer VIP in front of our DC's with a Verisign SSL certificate for LDAPS traffic -- and also some work to encapsulate what a typical application needs to know in order to use LDAP to talk to our AD, such as the paths to user and group objects within the OU structure.

We've noticed that applications large and small which claim to do "AD Integration" really just speak LDAP and authenticate by attempting an LDAP bind with a user's credentials. Making sure that the supported/documented way to do this against AD in a fully secure way in your environment is a win for both the application owners and for you as the functional owner of the AD. Make sure the applications understand LDAPS - not all of them do.

Doing this opens up all sorts of possibilities for easy AD integration with both local and cloud-based apps.

Hope this helps.

Cheers,

- Ken Hoover

--
Ken Hoover
Manager, Windows Systems Group (WINSYS)
Yale University ITS Infrastructure Services x2-1260
ken.hoover@xxxxxxxxxxxxxxxx * http://blogs.yale.edu/roller/page/kjh27

show

bdesmond posted this 19 April 2012

The LDAP stack would have to implement the DNS re-lookup/round robin behavior. SMTP does this well, but, you're unlikely to find it in an LDAP stack IMO. I've done the load balancer scenario many times. It works, although it has some challenges, particularly around doing something other than a simple bind.

Thanks,
Brian Desmond
brian@xxxxxxxxxxxxxxxx

w - 312.625.1438 | c   - 312.731.3132

show

kenhooveryaleedu posted this 19 April 2012


In our case, the primary purpose of putting the F5 in play wasn't for load balancing -- you can get a load-balancer effect by telling applications to point to the DNS entry that matches the domain name, which should be a multi-valued A record if your dynamic DNS is working properly -- but instead to establish a publishable VIP with a friendly-name DNS A record as a target to "speak LDAPS" to Yale's AD with a Verisign certificate securing the connection.

We have an AD-integrated PKI in place that works well for AD-specific purposes but it's self-signed at the root. Early experimentation with integrating applications from systems that aren't full participants in our AD -- such as *ix machines -- caused glitches because they don't trust the AD's root certificate.

This way, we could purchase one certificate from Verisign with our "friendly" name, install it on the F5 and get both benefits at once -- secure LDAP with a widely-trusted root for easier application integration with the F5 worrying about load balancing and keeping things happy when we need to do maintenance on domain controllers. This was far easier than educating a lot of people on how to import the AD's root certificate into their application's keystores.

Other universities have done the same thing for similar reasons.

- Ken Hoover

--
Ken Hoover
Manager, Windows Systems Group (WINSYS)
Yale University ITS Infrastructure Services x2-1260
ken.hoover@xxxxxxxxxxxxxxxx * http://blogs.yale.edu/roller/page/kjh27

show

slavickp posted this 19 April 2012

Connectivity checks performed by load balancers/automatic disabling of
unresponsive node can also come handy. Good for maintenance too.

I wonder if anybody is using NLB on DCs for LDAP access.

regards

Slav


On 19/04/2012 12:41 PM, Hoover, Kenneth wrote:
> In our case, the primary purpose of putting the F5 in play wasn't for load balancing -- you can get a load-balancer effect by telling applications to point to the DNS entry that matches the domain name, which should be a multi-valued A record if your dynamic DNS is working properly -- but instead to establish a publishable VIP with a friendly-name DNS A record as a target to "speak LDAPS" to Yale's AD with a Verisign certificate securing the connection.

show

bdesmond posted this 19 April 2012

You have to configure affinity on the load balancer to make sure this doesn't happen.

Thanks,
Brian Desmond
brian@xxxxxxxxxxxxxxxx

w - 312.625.1438 | c   - 312.731.3132

show

skitzsofrenick posted this 19 April 2012

We use round robin in an F5 BigIP with persistence and the load is as even
as you can get across 5 ADDS in the pool.

On 4/19/12 10:28 AM, "Brian Desmond" <brian@xxxxxxxxxxxxxxxx> wrote:

>You have to configure affinity on the load balancer to make sure this
>doesn't happen.
>
>Thanks,
>Brian Desmond
>brian@xxxxxxxxxxxxxxxx
>
>w - 312.625.1438 | c - 312.731.3132
>
>

show

bdesmond posted this 19 April 2012

Yup - should work quite well. I probably would have gone with least connections as the predictor but for LDAP traffic it probably makes little difference when I think about it.

Thanks,
Brian Desmond
brian@xxxxxxxxxxxxxxxx

w - 312.625.1438 | c   - 312.731.3132

show

RaviSabharanjakblackrockcom posted this 23 April 2012

You could schedule an ADRAP to proactively look at a lot of problems that affect availability.

show

barkills posted this 23 April 2012

<jumping in mid-thread with a comment specific to this point>

We have had very good success with adding the domain's FQDN as a SAN (subject alternative name) on the cert we stick on each DC + just having LDAP-integrated apps point at the domain's FQDN as the LDAP server host name + just using round-robin DNS. With this configuration, we haven't yet run into any LDAP-integrated app which supports LDAPS which chokes on multiple DCs. That said, I imagine that now that we have a load balancer, we'll eventually move to it instead.

I'd note that if you do the cert trick, the CN must still follow the normal AD-DS cert rules with that DC's FQDN as the CN. You just also add a SAN with the domain's FQDN. That means not using the DC cert template (we don't use AD-integrated CA), but it's now very easy to create a custom cert request for this purpose with any OS later than WS2008.

show

bdesmond posted this 23 April 2012

The DC's name can also go in SAN #1 and the domain name/VIP in the subject name. I've seen lame apps choke and not support the SAN thing.

I use DigiCert's free tool - www.digicert.com/util for generating CSRs to 3rd party CAs on DCs.

Thanks,
Brian Desmond
brian@xxxxxxxxxxxxxxxx

w - 312.625.1438 | c   - 312.731.3132

show

RaviSabharanjakblackrockcom posted this 23 April 2012

Our experience using the domain name was:
- It is hard to perform maintenance on the DC, a DC could keep getting requests directed at it even though it is down, being patched etc unless it's A record registered for the domain name is removed.
- the round robin may connect you to a non-local server. Ie: client in the USA connecting to Hongkong etc.
- If there is an issue, it is hard to figure out which DC to look at, as the client could be connecting to any DC.

It might be tricky to move this to the load balancer - the load balancer would most likely need you to redirect the name resolution of your domain name to the load balancer setup, so that it can reply with the address of the closest server. You would most likely need to use a different name for connecting your clients to a LDAP server, as you would not be able to direct the name resolution of your domain name to the load balancer.

show

stadler17 posted this 23 April 2012

Jason,

I am at this point planning to use the same text book.

Thanks,
Ryan

Brian Arkills <barkills@xxxxxxxxxxxxxxxx> wrote:


<jumping in mid-thread with a comment specific to this point>

We have had very good success with adding the domain's FQDN as a SAN (subject alternative name) on the cert we stick on each DC + just having LDAP-integrated apps point at the domain's FQDN as the LDAP server host name + just using round-robin DNS. With this configuration, we haven't yet run into any LDAP-integrated app which supports LDAPS which chokes on multiple DCs. That said, I imagine that now that we have a load balancer, we'll eventually move to it instead.

I'd note that if you do the cert trick, the CN must still follow the normal AD-DS cert rules with that DC's FQDN as the CN. You just also add a SAN with the domain's FQDN. That means not using the DC cert template (we don't use AD-integrated CA), but it's now very easy to create a custom cert request for this purpose with any OS later than WS2008.

show

skradel posted this 23 April 2012

Ravi, I'd agree with all of this; it's often preferable to configure
multiple, server-specific LDAP URIs for an application that supports
it (as almost all LDAP client APIs support some level of failover).
While this provides no load balancing at all, RR DNS is, for all the
reasons you detail, not really a supportable approach.

The case where "domain name only" works really well is with APIs,
including those already baked into .NET, that understand the DC
Locator process. In this case you do get a connection based on site
link costs and OK failover, although any load balancing within the
local site is just quasi-random.

SSL-terminating load balancers in an HA config with sticky sessions is
probably the nicest approach; it's a tough call whether to reinitiate
SSL between the load balancer and DC unless policy requires it.

--Steve

show

Close