Thursday, March 12, 2015

(Sort of) Dynamic Security Groups in Active Directory

Working with a customer who is migrating from Novell to Windows, I was asked if Active Directory has dynamic groups. In eDirectory, you can create a group whose members are determined by the result of an LDAP query. Active Directory doesn't have this functionality. There are dynamic distribution groups with Exchange, but those aren't security groups.

I'm not a Powershell guru by any means, but I created a small Powershell script that would perform a query, remove the members of a security group, then replace the members with the results of the query. Over lunch, my wife asked, "What if I logon at the exact moment the group membership has been cleared?", which led me to make some changes. The script now creates two arrays - one containing the current group members, the other containing the results of the query. I then compare the contents of the arrays, removing current group members that aren't in the query results, and adding group members from the query results that aren't already in the group. That way, anyone currently in the group who are also in the query results is left alone.

Because Powershell works with objects and is pretty smart about it, I first tried comparing the entire array to the other array member with "If (-Not ($current.Contains($new[$i])))", but that didn't work - the If statement was never true. I found that it does work if I specify the name property, as shown below. Note that the first element of an array is 0 (zero), so an array with 20 values will have element 0 to 19.

Here is the final script:

$current = @(Get-ADGroupMember groupname)
$new = @(Get-ADUser -Filter {Name -like "*"} -SearchBase "ou=Users,dc=your,dc=domain" -SearchScope Subtree)

For ($i=0; $i -lt $new.count; $i++) {
   If (-Not ($current.name.Contains($new[$i].name))) {
   Add-ADGroupMember groupname -member $new[$i] -Confirm:$false
   }
}

For ($i=0; $i -lt $current.count; $i++) {
   If (-Not ($new.name.Contains($current[$i].name))) {
   Remove-ADGroupMember groupname -member $current[$i]
   -Confirm:$false
   }
}

Replace the group name and OU path with your own. It selects all users in or under the OU path, but you could have any filter you wish. For example, you could use {Surname -Like "Smith"} if you wanted to find all the Smiths in your organization.

Lastly, create a scheduled task to run this on a regular basis. Every 30 or 60 minutes is probably adequate. It's not a dynamic group, but it's pretty close.


Sunday, February 9, 2014

It's raining passwords!

Scenario
Novell eDirectory and Microsoft Active Directory are connected using Novell (NetIQ) Identity Manager. Bidirectional password synchronization is enabled, but synchronization from AD to eDir is not working. The password filter (pwfilter.dll) is installed on all the writable domain controllers and show as Running. Users change their password in AD, then call the help desk because their password hasn't changed in eDir and all the other connected systems. The help desk changes their password in eDir and all seems well.

But... It's not. There's a hidden danger lurking on the domain controllers, and one wrong move can unleash a torrent of stale passwords just waiting to synchronize to eDirectory, and by extension to all connected systems. Has it happened to you? It's happened to me, to the tune of 2,000 passwords suddenly changing to values set many months ago.

I've done a lot of research trying to resolve the AD to eDir password sync issue for the customer, and I didn't find anything warning me about the dangers of stale cached passwords. Now that I've searched for specifically that possibility, I've found a few that briefly mention it and one TID that specifically addresses the issue, but none that has what I consider an appropriate warning. Every article addressing AD to eDir password synchronization issues should include something like:

WARNING: Disable AD to eDirectory password synchronization or clear out the cached passwords on all DCs prior to troubleshooting AD to eDirectory password issues or you might sync old passwords and expiration dates to every other attached system and lock out thousands of accounts!

Let me give a quick explanation of how AD to eDirectory password synchronization works. A user could potentially change their password on any DC, so every DC runs a password filter that captures the changes and stores them in the registry. The security settings prevent anyone - even Enterprise Administrators - from seeing these entries (but keep reading for a way to do it without meddling with permissions). The password changes are sent to the DC running the remote loader, which stores them in its registry (or, if there is no remote loader, the DC running IDM). That DC reads its own registry, then sends the passwords on to eDirectory.

A little aside here. I realize I haven't posted screenshots or snippets of code or log files. This is primarily because I'm posting what I've encountered at customer sites, and I don't want to identify my customers nor their system configurations. I apologize if this makes things a bit more difficult to follow, but feel free to contact me directly and I'll try to clarify anything or help you with your specific issues.

Until recently, cached passwords never timed out (and even with current code that isn't the default setting). If a DC wasn't able to send its cached passwords to IDM, they stayed there indefinitely. If somehow the DC was able to communicate with IDM, the cached passwords would be processed as if they were new, changing the password in eDirectory, and by extension every other attached system. In addition to the password itself, the cached data contains the password change time and expiration date.

How to see cached passwords in the registry without changing permissions
They are visible only to the local SYSTEM account, so the trick is to run regedit.exe as that account. You can do this using psexec.exe from SysInternals, which can be downloaded here: http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx.

Extract the download and then copy ONLY psexec.exe to each of your writable domain controllers. Run CMD as Administrator (Start | Search for CMD | Right-click and choose Run As Administrator). Run "psexec -i -s -d CMD", which will launch a new CMD as SYSTEM. From there, run regedit.exe and navigate to HKLM/Software/Novell/PwFilter/Data. You'll see one key per cached password, i.e. HKLM/Software/Novell/PwFilter/Data/ABRADLEY. If the user has changed their password on the DC more than once, only the most recent password will be stored. BUT - if they've changed their password on more than one DC, there will be a separate entry for the user on each of those DCs. For the Remote Loader DC, the path is HKLM/Software/Novell/PassSync/Data.

To see WHEN the password was last changed on that DC, export that registry key, save as .txt, and then open the export with a text editor.

How I "Fixed" Password Synchronization
In this instance, it was the Windows Firewall on the Remote Loader running on Windows Server 2008 R2. When I disabled the firewall, the communication between the other DCs and the RL was open and the cached passwords came flooding in. I could see what users were impacted by looking at the log files, as it showed each username, first in a long list of arriving cached passwords, then again when processing each password.

References
How to Prevent Syncing Old Password Changes from Active Directory

View Registry Key Timestamp

Getting a CMD prompt as SYSTEM

Remote Loader on Windows 2008 R2 and PWFilter Firewall settings

IDM Password Sync Components

DC Passwords TimeToLive (Cached Password Timeout)

Thursday, January 23, 2014

Excellent tool - A.F.9 Replace some bytes

A few months ago I needed to replace a number of object names in a number of files. My first thought was to load a file into a text editor, do a search and replace for each object name, save the file, and repeat for each file until done. It seemed this would be time-consuming and error-prone. I set out to find a tool that could do that in one step. Lo and behold, Alex Fauland had created just the tool I needed - A.F.9. This ingenious tool allows you to create a list of strings, and what string to replace each with. The list is stored as XML and looks like this:

<FIND TYPE=ASC>string1</FIND><REPLACE TYPE=ASC>newstring1</REPLACE>
<FIND TYPE=ASC>string2</FIND><REPLACE TYPE=ASC>newstring2</REPLACE>
<FIND TYPE=ASC>string3</FIND><REPLACE TYPE=ASC>newstring3</REPLACE>

Though I've only used it for ASCII (ASC), it also supports decimal and hexadecimal strings - and even lets you replace one type with another. It can overwrite existing files, or create new files. It reports how many times a replacement is made on each file.

Thursday, January 16, 2014

IDM and Revealing Passwords

Aaron Burgemeister published a great tool to export eDirectory passwords to a CSV file using an IDM delimited text driver. You can find it here. But there may be times that you only need one or two passwords and you don't want to create a delimited text driver.

I've used a different method to reveal passwords in the driver log file. Though nspmDistributionPassword is not shown in the driver log file, local variables are - even when the local variable was set to equal nspmDistributionPassword!

I'll leave it to you to write a rule to set a local variable equal to nspmDistributionPassword, and to create a method to trigger the rule.

Tuesday, January 14, 2014

The name and the URL

I originally created a blog named "That Novell Guy", because that's what I often am at work. Some know me from when I worked for Novell while others know me from my current position with Enterprise Networking Solutions, where I'm the go-to Novell engineer. I decided to change it because I didn't want to risk getting in trouble with Novell. That, and I don't want to be seen as just the Novell guy.


I changed the blog's name to "Nothing Changed" as an homage to the nearly ubiquitous answer to one of the first questions we ask when told something stopped working. What changed? Was any software or hardware installed/removed/updated? Nope, nothing changed. :-)


As for the URL, well... I tried a bunch of different addresses and couldn't find one I liked, so I wracked my brain. "Something, something, something, Dark Side" from Family Guy popped into my head. I subtracted one something (RAID1 instead of RAID5), added my title, and there you have it.

Introduction

My name is Adam and I'm a Systems Engineer. I've been doing this for about 20 years, both as a pre-sales and post-sales engineer. My intent with this blog is to document issues that stymied me for a while, but was eventually able to solve. Also, I may post about nifty utilities and exactly what I've done with them.


A lot of my experience is with Novell solutions, especially NetWare, eDirectory, GroupWise, and Identity Manager. Even today many of my customers run Novell solutions, though most are working to migrate off of them. To that end, many of the issues I've faced and tools I've used have been in the service of migrating from NetWare and eDirectory to Windows and Active Directory.


Over the years, I've found that solutions are found in product documentation (RTFM), my peers, knowledgebases - but often from individual blogs and forum posts. I'm hoping that this blog will help others when they encounter similar issues. Also, feel free to add/correct/augment my posts as needed!