Recently, I wanted to provide a client with a list of groups that related to some work he was doing. I wanted the group names as well as their location with AD. Although I often use the ds* commands or excellent ADfind tool for this type of task, I had been working in PowerShell on another project, so I decided to use the PowerShell ActiveDirectory module.
The Get-ADGroup Cmdlet pulled out the groups easily enough, but the there wasn’t a property representing the group object’s parent, nor is there an LDAP property that I could request (AFAIK). The object’s parent is contained within the DistinguishedName (DN) property, though.
For a group with the following DN:
I just need to strip off the CN. I could split the DN on commas, remove the first element, and then reassemble what’s left to get the parent. I also needed to avoid splitting on an LDAP-escaped comma where a value actually contains a comma (e.g., CN=).
PS> $dn -split '(?<![\]),'
On Server 2008 and 2008 R2, if your Domain Controllers aren’t configured to require LDAP signing and disallow simple LDAP binds in plaintext, Active Directory Domain Services logs a warning event on startup, and summary events every 24 hours.
A couple weeks ago, I followed the recommendation to enable logging of unsigned and plaintext LDAP authentication requests. Setting the LDAP Interface Events value to 2 generates a Directory Services event 2889 for each connection.
Now I want to do some analysis of the collected events. The event structure puts the important details, namely the client name and IP address, in the big description text field. It looks like this:
Log Name: Directory Service
Date: 11/3/2010 11:46:38 AM
Event ID: 2889
Task Category: LDAP Interface
User: ANONYMOUS LOGON
The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification), or performed a simple bind over a cleartext (non-SSL/TLS-encrypted) LDAP connection.
Client IP address:
Identity the client attempted to authenticate as:
Previously, I’ve exported the logs to CSV format, then used Excel and some text-mangling functions to pull out the important details. But I noted that the two important values were nicely separated in the XML representation of the event:
I’ve been working on deploying a load-balanced Remote Desktop Gateway service. I deployed the first farm member, then cloned it to create a second member. The second member was throwing Error events, which has the description "There is no domain controller available for domain CAMPUS."
Now, I know that the domain controllers are up and available. I remembered having fixed this at some point with the Terminal Services Gateway box I set up originally.
Google pointed be to a technet blog entry describing the solution(s).
When I selected Register server in Active Directory, I received an error because the account I was using didn’t have rights to modify the the AD objects. And that explains why this system as having the problem: when I joined the cloned system to the domain, I was not using a domain admin account.
I logged back in as a domain admin and reran the registration step. Done, and blogged for my future reference.
I’m in the process of deploying a couple new Server 2008 R2 domain controllers. I’m using two IBM blades, each having a pair of Broadcom NICs that I configured in fault-tolerance teams.
In trying to verify the configuration of one of the DCs, I used the command:
The output surprised me:
Starting test: Connectivity
Message 0x621 not found.
Got error while checking LDAP and RPC connectivity. Please check your firewall settings.
......................... CDC01 failed test Connectivity
I ran the command from a Server 2008 Sp2 (not R2) host:
dcdiag /s:cdc01 /test:dns
The test passed without error. Strange. I verified firewall and DNS. Then turned to the hivemind. This post shows similar behavior. This post on the TechNet forums identified the NIC Team as a probable source, and a contributor referenced a hotfix KB978387 for a bug in dcdiag on Server 2008 R2 on systems with NIC Teams.
Installed and now the test passes:
Starting test: Connectivity
......................... CDC01 passed test Connectivity
I spent much of my day working on this, and on tracking the connections to AD by clients using unsigned SASL binds or LDAP simple binds without an encrypted connection.
During an upgrade of our VMware ESX infrastructure, I ran into an issue with our domain controllers. As part of the process we needed to upgrade the virtual hardware that is part of the guest vm. After updating the domain controller guest’s VMware Tools software, I shut down the guest and select Upgrade virtual hardware. Things looked good, so then I powered on the guest and it started to boot. After a moment, it threw a quick bluescreen and auto-rebooted.
My first order of business was to change the auto-reboot option so I could actually see the error message. I know now that I could just hit F8 during the boot process. However, I did it the hard way.
I booted to the Windows 2008 install media, and ran regedit from the recovery environment. I loaded the HKLM hive, and set the HKLMSYSTEMCurrentControlSetControlCrashControlAutoReboot DWORD value to 0 (zero). I see in the KB 307973 article that there’s also a wmic command that will set the option. I don’t know if wmic is available in the WinPE recovery mode.
Working on the Server 2008 hard limit of 5000 attribute values max per query, which breaks our Identity Management process. I’m looking at having to write a clone of LDIFDE that can issue queries using Range Retrieval and then synthesizes a single LDIF entry for groups with more than 5000 members.
Safari Tech Books online provides some good resources, including The .NET Developer’s Guide to Directory Services Programming [at Amazon], which provides a good code example in Listing 6.8. Range Retrieval Using DirectorySearcher.
Or maybe I should just post-process the LDIFDE-generated LDIF file…
It’s June! Cold and rainy?! Gah!!
On the list for today:
- AD Domain Services on Server 2008 and Operations Manager 2007
Operations Manager – verifying current version
Post regarding installing hotfixes on the Management Server using SetupUpdateOM.exe. Never heard of it before. Doesn’t exist on my system. Perhaps it’s part of OPs Mgr 2007 R2?
I decided that the KB956184 patch looked the most promising. Because the installation involved manual replacement of msi files in the AgentManagement folder on the Root Management Server, I could back-out the changes if things went South.
After renaming the original 64-bit OOMADs.msi files and replacing them (AMD64 and IA64 versions) with the ones from the hotfix. Then I used the OpsMgr console to uninstall the agent from my four Windows server 2008 AMD64 domain controllers, one at a time. For each I verified that the new AD MP Helper Object was installed, checking appwiz and Program FilesCommon. Then I checked the Operations Manager Event Log. This time, there were no errors running the DSDiscovery script. Health explorer on each DC is now clean. Yes!!!
The only lingering issue is the presence of five errors in the event logs on each DC, complaining about the inability to locate Performance Counters for DirectoryServices: “DS Search sub-operations/sec”, “LDAP Client Sessions”, “LDAP Searches/sec”, “LDAP UDP operations/sec”, and “LDAP Writes/sec”. I verified that I could see these counters within Performance Monitor on the DC. This thread in the OpsMgr Management Pack newsgroup seems germane, though the Live login isn’t working for me at the moment.
Managed to chime in on that thread. We’ll see if anything useful comes of it.
Having successfully deployed some agents to some recalcitrant hosts, I’m now trying to address a false positive issue on a DC. I’m getting an error regarding “AD Op Master Respone [sic] Monitor”. The host has a recurring error:
AD Op Master Response : The script ‘AD Op Master Response’ failed to create object ‘McActiveDir.ActiveDirectory’. This is an unexpected error.
The error returned was: ‘ActiveX component can’t create object’ (0x1AD)
This led me to a blog post suggesting that the AD Helper Object needed to be installed. So I look in the OpsMgr host’s AgentManagement location and find the msi. When I tried to install that msi package, I received an error that the “this installation package is not supported by this processor type.” The host is running AMD64 Windows, and the file came from the AMD64 part of the AgentManagement tree.
I checked the list of installed apps on another x64 DC, and saw that the “System CenterManagement Pack Helper Objects” item had been installed. So I tried repairing the agent install from within Ops Manager. Error persists.
Checking the hotfixes required to make Ops Manager agent work on Server 2008, and they are missing. Stay tuned…
Applied the hotfixes and still no love. I did dig into the eventlog, and saw that it appear the ADDiscover script failed in some way. I tried running the script manually (using the arguments from the eventlog entry), but it still failed. I fell back to google and found the following promising KB article: Alerts are issued from the MOM Active Directory Management Pack after you install an Operations Manager 2007 SP1 agent over a MOM 2005 agent on a domain controller that is running a 64-bit version of Windows.
Now this KB article describes a set of circumstances that don’t match my situation. I didn’t install MOM 2005 agent and then the OpsMgr 2007 agent on the same host. This system was built from the ground up with server 2008 x64 and Operations Manager 2007 was deployed here way before server 2008. However, the constellation of symptoms and architecture issues make it sound interesting.
Just found Kevin Holman’s blog and his list of hotfixes. I must go read about these and OpsMgr SP2 before doing anything drastic. Nothing like breaking the server late on a Friday…
Working through the AD preparation for an application install, and I’m logged into the emtpy root domain as a schema admin. Running the setup application, I get an error indicating that I don’t have rights to
Organization Preparation ……………………. FAILED
You do not have permissions to read the security descriptor on CN=Deleted O
I need to confirm I can read the security descriptors for this object. Found a KB Article:
Viewing deleted objects in Active Directory
Before I dig deep with that, I also found this forum thread, suggesting that running the setup command in a console connection rather than RDP might help. I’m going to give that a try first.
Nice; that’s all it took. Onward and upward…