Skip to content

Kerberos Time Skew – my eyes aren’t deceiving me

A couple of times while troubleshooting something else I have noticed that Kerberos still works even if the time skew is greater than 300 sec. On other occasions I have definitely seen it fail. As far as I knew this wasn’t supposed to happen, but I never got round to following it up as I was too busy with the original issue (and besides, it’s easy to fix; just set the time service to work properly!). Now finally here is an explanation from the AskDS guys as to why this is:

The semi-myth of Kerberos time skew

And the Technet article that I could never find but assumed must exist:

Kerberos tickets are issued even though etc

Caching AD info using DirectorySynchronization

A client had a bespoke identity management app which cached AD group information so they could have autocomplete of group names on a self-service access request webpage. To keep their cache updated they were querying each DC in the domain (over 30) to get the highestCommittedUSN, then picking one at random to get groups with a newer USN. In this way they would never have to do a full sync, even if the DC they usually talked to failed (crazy way of doing it!). We needed a better solution, and I knew a way to do this using standard MS tools.

The standard System.DirectoryServices.DirectorySearcher can be configured to take a DirectorySynchronization control which saves a cookie of the directory state when it is run, so only deltas are shown when you run next time. The directory searcher can contain your usual LDAP string, in my case (objectClass=group).

I simply created a standard search using DirectorySearcher and then added a new DirectorySynchronization control. On first run, this has the effect of taking a baseline (all groups in this case) and dumping them into a list (this took say 20 secs for 70k groups). A cookie is generated which stores information about the state of the directory at this instant, and I get this with GetDirectorySynchronizationCookie() then write out to a text file (approx 1KB in size).

On subsequent runs, this cookie file is read using ResetDirectorySynchronizationCookie() and used to tell the searcher to only pickup changes since last time it was run then output these as a list. Depending on which attributes you specify to return you can get all sorts of changes here, but I specifically wanted add/delete/rename of groups. By specifying ExtendedDN and name as the to attributes this gave me name, DN, objectGUID and objectSID which was sufficient for the identity management app to update its cache.

The changes seen are add, delete and rename. Delete is obvious (see below). Whether you add or rename a group it appears the same but of course having the SID or GUID your app can see that this is either a new object or rename of an existing object.

This even works when the baseline is generated on one DC and the delta on another. Full code is below:

// a class to contain a single group result
    public class GroupInfo
        public string Dn { get; set; }
        public string Name { get; set; }
        public string ObjectGuid { get; set; }
        public string ObjectSid { get; set; }

    public static List<GroupInfo> GetGroups()
            string sLdapServer = "LDAP://yourdc";
            string sLdapFilter = "(objectClass=group)";
            // file where cookie will be stored
            string sCookiePath = @"c:\temp\dirsync.dat";
            // configure directory search
            DirectoryEntry dir = new DirectoryEntry(sLdapServer);
            DirectorySearcher searcher = new DirectorySearcher(dir);

            searcher.Filter = sLdapFilter;
            searcher.SearchScope = SearchScope.Subtree;
            searcher.ExtendedDN = ExtendedDN.Standard;

            // create new dirsync object
            DirectorySynchronization sync = new DirectorySynchronization();

            // check whether a cookie file exists and if so, set the dirsync to use it
            if (File.Exists(sCookiePath))
                byte[] byteCookie = File.ReadAllBytes(sCookiePath);

            // assign dirsync object to the searcher object
            searcher.DirectorySynchronization = sync;

            // iterate over search results and enter into a list
            List<GroupInfo> liGroups = new List<GroupInfo>();

            foreach (SearchResult result in searcher.FindAll())
                GroupInfo giGroup = new GroupInfo();

                giGroup.Name = (string)result.Properties["name"][0];
                string[] sExtendedDn = ((string)result.Properties["distinguishedName"][0]).Split(new Char[] {';'});
                giGroup.Dn = sExtendedDn[2];
                giGroup.ObjectGuid = sExtendedDn[0].Substring(6, 36);
                giGroup.ObjectSid = sExtendedDn[1].Substring(5, sExtendedDn[1].Length - 6);

            // write new cookie value to file

            return liGroups;


        // catch LDAP errors
        catch (Exception exc)
            List<GroupInfo> liGroups = new List<GroupInfo>();
            GroupInfo giGroup = new GroupInfo();
            giGroup.Name = String.Format("Error attempting to get data from LDAP: {0} ", exc.Message);
            return liGroups;

Server 2012 AD Install

Server 2012 Release Candidate landed yesterday. I decide to install on my portable lab environment, where I already have a Win8 AD setup.

VMware workstation doesn’t know 2012/win8 yet so you need to choose ‘install OS later’, then selecting 2008 R2 as the target OS seems to work fine.

So MS have chosen a nice new blue for server 2012, I like to think there is a focus group somewhere at Redmond that spent ages choosing the particular shade 🙂 I also like the new monochrome logo styling, cf win8/ie10.

The install is really quick, not like the good old days. Once installed and networking/computername configured it’s time to dcpromo. This is all done through the role/feature system now.

Select Active Directory Domain Services, and DNS (assuming you want this to be a DNS server), then a few next/nexts and Install.

Once installed, next step is to actually Promote this server to a domain controller.

The config steps are broadly similar to previous versions (and the same as win8 obviously). I am adding to an existing Win8 Beta AD domain.

The install when adding to a domain/forest suggests it will need to run the adprep functions. This is being added to a Win8 forest which in theory is the same, but perhaps they have had to do some schema updates to change ‘8’ into ‘2012’ and fix whatever else they found wrong with the beta.

I ignored the messages about DNS delegation (there isn’t one in my lab) and NT4 cryptography, then went ahead and let it configure. It reboots and you are done. I checked and it disagrees with the win8beta DC as to what the functional level is called:

But a quick check of msDS-Behavior-Version shows it to be the same level, 5.

So all went fine, my win8preview and samba clients can connect with no problems and the domain didn’t spontaneously combust, all replication etc checks out fine. Having said that, I haven’t managed to get the win8 beta version to crash yet, lots of dogfooding by Microsoft means betas aren’t what they used to be!

kpasswd and Windows clients

So one of the firewall guys asked me about some drops on port 464 (kpasswd) for a new client location we setup in Paris. I was under the impression MS included kpasswd for UNIX interoperability, as I was pretty sure that MS operating systems didn’t use it. No issues had been reported changing passwords, even though many new users were at the site and would have been forced to change. Some new Windows 7 machines had been installed at the site, some of the first at our organisation (yes we are behind!).

I couldn’t get hold of any users onsite so I got wireshark on a test W7 machine talking to a test 2008 functional level domain and took a look at the traces when changing password using ctrl+alt+del ‘change password’ option. Sure enough, Win7 uses KPASSWD protocol to change passwords. From the trace below (filter “dns || ntlmssp || kerberos || samr”) you can see the client sends AS_REQ to the authentication server and obtains a ticket for the kadmin/changepw SPN (another type of ticket the AS issues besides the TGT):

On receiving the response it sends the KPASSWD packet to the DC and receives the response (you can take my word for it that it was ‘success’), then issues new requests based on the new password:

I tested various scenarios and in fact the same situation occurs for Win7 clients talking to 2003 (functional level and all 2003 DCs), whether this is a client and server in same forest, or in different domains both forest trust and external trust. (This was the situation with the site we setup, since that domain was at 2003 level.)

The situation when using an XP client is entirely different (I didn’t have a Vista client to test – who does in a commercial environment?). XP always uses SAMR (RPC-over-SMB, on 445/tcp), whether it is talking to a 2008 or 2003 based domain, either in the same forest or a trusted (external or forest) domain:

On my test Win7 box I blocked port 464 tcp/udp and sure enough it still allowed the password change, but reverted to SAMR like XP (in my trace I guess you don’t see the KPASSWD request since Comodo firewall blocked it before Wireshark saw it):

So, given that Win7 ALWAYS defaults to KPASSWD (for any 2003 or 2008 domain, trusted or single domain) why isn’t _kpasswd port 464 in the Microsoft list of domain ports that we supply to our firewall teams?

EDIT: looks like they added it finally, better late than never…

Powershell Script Explorer beta released

Microsoft have released a beta version of the Script Explorer for Powershell:

Looks pretty good, as long as I can get some custom repository locations configured (which is apparently possible). This should save my team some duplication of scripts and snippets, and also improve our plagiarising re-use of IP 🙂