So here’s a question I want you to try answering off the top of your head – Which certificate is your domain controller using for Kerberos & LDAPS and what happens when there are multiple certificates in the crypto store?
The answer is actually pretty obvious if you already know the answer, however this was the question I faced recently, and ended up having to do a little bit of poking around to answer the question.
The scenario in question for me is having built a new multi-tier PKI in our environment I have reached the point of migrating services to it, including the auto-enrolling certificates templates used on Domain Controllers.
If you are an Active Directory Administrator, Check out this presentation by MVP Jess Dodson on AD Security and Maintenance which was presented in the main hall at MSIgnite NZ a couple of weeks ago.
Some of you may already be familiar with Jess’s work over at Girlgerms Online and if not, these is definitely one of the better systems administration blogs in Australia 🙂
Edit 6/11/16 – WordPress is not correctly embedding video – looks fine in editor, but shows a link when published. have updated URL to direct link to the Channel 9 site.
Its been a busy month for me, as is always seems to be the case from about Mid-November all the way through to Christmas. My focus at the moment has been decommissioning legacy systems, of which one is particularly notable.
The last Windows Server 2003 Domain Controller in our environment gets decommissioned this week. This has been the culmination of works started in August 2009 in an effort to modernise Active Directory where I work. Upgrading AD where I have been working has not been that much of a priority, and there were both political and perception challenges to overcome as well. Some of the things that have happened as part of this work have been significant infrastructure changes including:
- Making Domain Controllers purely a single role machine.
- New DCs in sites where previously one machine acting as a DC and Fileserver
- Removal bof additional roles from domain controllers (e.g. RADIUS Auth, Certificate Authority, Scripts etc)
- New load balancing of LDAP & LDAPS connections for applications which only allowed a single authentication source
- Modification of firewall rules due to the changes in open ports in Server 2008 R2.
We got to the point of decommissioning in July 2012, but that attempt had to be aborted following some applications having unexpected issues.
But this week we are finally there. The server has been turned off for a few days to make sure there aren’t any more surprises, and this week we will shut down the server, wipe the drives and add it to the pile of decommissioned hardware.
With that done and dusted, we only need to raise the Functional level to 2008 R2 native before starting the process again with WS2012.
Its been a couple of months since I last posted, and it’s more because I have been just really busy with work more than anything, with not a lot of time spent on scripts. So instead I’ll post about some things I have been working on and people are welcome to do a Q&A in the comments forum:
Remember WINS? The NETBIOS name resolution service before DNS? Yea me either. It was however rather widespread throughout where I worked though, with the big problem being that the service was a window component that was installed but not managed as a service.
What I learnt about this was that ownership of WINS records are very important. where multiple WINS servers are replicating and one server is decommissioned, all the records associated with that server will remain active (at least that is what happened for me). As a result, there were some 60,000 WINS records in an environment with less than 9000 machines.
As a result there has been a project since December 2011 to remove WINS settings from all DHCP Scopes and manually removed from all Static IP hosts, and gradually decommission the WINS Service. The static IP removal was made much easier using my DNS & WINS Update script. In early March the job was complete, with only a couple of legacy servers having access to a WINS service on a machine. Only two machines out of the 9000 had issues raised, one of them being an NT4 (!) machine. Quite Successful.
We’re finally getting rid of WINS at work. Remarkably we still have some production applications that require it, but that is being worked on. In the meantime I am working at removing WINS settings from DHCP Scopes and from servers where we know WINS is not required.
While DHCP scopes are easy to update, static assignment on servers aren’t. Theres no magic GPO you can set and be damned if you do it by hand for over 500 servers. Thankfully WMI as we have previously seen will allow a scriptable way to update network adaptor properties.
So I have written a script to do automate the process. The script uses Quest AD Management cmdlets for Powershell.
Download the script here
How to run the script follows
I’m doing a bit of work in preparation to upgrade our MS Exchange environment. One of the requests made was to identify AD accounts which had a duplicate CN. This may occur when you create users with the same name, but in different OUs in Active Directory.
I came across this post by Scott Lowe in 2006 about doing it with dsquery and logparser, but with Powershell now available I could do it in this instead.
Below is the 2 lines to do this. Note I use Quest AD management cmdlets, so you may need these.
$users = Get-QADUser -Sizelimit 0
$users | group name |sort count -descending
Yes, it’s really that simple. Duplicate account names are rare in AD, so with this command if there are any, they should appear in the first few lines. If you have a lot of user accounts, I recommend piping this out to file and opening in a text editor.
The first I knew there was a problem was when the support calls started coming in – “Our Network drive is missing!”. It couldn’t possibly have been what I was doing, creating a DFS namespace Root with the same name as one of our network shares. It has been tested as ok, and accepted through change management so why were people calling? In the post mortem, it became clear – the testing had been against DC, but in production a number of our DCs were file servers too and the DFS Root share had “stolen” the existing share.
Time to see what shares were on DCs/File Servers and pick a unique share name