I am playing with a new utility I was challenged to write at the latest MVP Summit. It is a command line utility to manage msDS-PasswordSettings objects and I ran into a weird issue where one of my GC queries wasn’t finding what I thought it should be finding. So as a point of first resort, I fired up wireshark and start tracing the calls and when I went to check out the calls they were all encrypted… WTF. I went and checked to make sure I didn’t enable encryption and I didn’t… Oh wait domain policy GRRRRR.
So I go to pull up the domain policy editor and turn down the security (Shhh don’t tell anyone) and low and behold, the Feb customer preview of Longhorn doesn’t have a policy editor in it… Ah yes, I recall, it was purposely not in there for this version, the GPO folks did say that… It will definitely be in Beta3…
I knew I could fire up a policy editor on a client and tweak it that way but I have no clients in the Longhorn test domain and I wasn’t interested in testing how well the policy editor on a machine from Windows Server 2003 R2 DomainX would work on a Longhorn DomainY so I just decided to tweak the registry on my test client machine directly. How you ask? Great question and why I wrote this blog entry.
You want to go into the registry, specifically to the key
hklm\system\currentcontrolset\services\ldap
and look at the value called ldapclientintegrity and set it to 0.
Rerun my app and voila… Instantly I can see the LDAP traffic in clear text again.
So what was the issue you ask??? Silly stupid issue actually, related, interestingly to the fact that I was running the utility on a machine that wasn’t a member of the Longhorn domain. I can’t believe I made the mistake as it is a stupid mistake. In order to work from a non-trusted machine I allow, like with adfind, the ability to specify a specific host. That worked great, but then I went chasing after a GC and well the locator by default went after a GC for the domain the machine was part of, not a GC of the test Longhorn forest. So duh, yeah, it didn’t find what I was looking for because it only existed on the Longhorn domain. I corrected it by doing a quick manual lookup via DsGetDCName to get a GC in the Longhorn forest based on the info from the RootDSE of the specified host.
So why do I test this way instead of spinning up a client in the test forest? Because I like catching problems like this. I want my utilities to work under those conditions because 99% of the time I have to use the utilities I am not in the forest I am running the utilities against (usually in workgroup mode). Once I have a good chunk of the code written I will start running it from domain joined machines as well but in general, if it works from outside of the domain, it will work fine within the domain.
joe
