My not so uninteresting notes

To content | To menu | To search

Monday 17 October 2011

Interoperability lab 2011

2 weeks ago I finished my trip in the US back from the SNIA's SDC and interoperability lab at Microsoft in Redmond. I won't talk much about SDC because my friend and long time team member, Chris Hertel, already did it, like last year it was a great moment of fun, and a pleasure to meet other team members. And as some Microsofters that participate at the AD interoperability lab are also at SDC, it's a kind of warm-up for the next week event: Active Directory interoperability lab.

This was the 4th edition of this lab between Microsoft and the Samba-Team, and my second participation. We usually achieve some terrific results during this lab because of the emulation created by face to face discussion and coding of team members and also because Microsoft provides us both a test infrastructure and real-time support with their engineers on issues that are found during the lab. In 2009 we managed to make directory replication work, opening the way to a first class citizen DC for Samba, in 2010 we worked on read-only DC, BackupKey procotol and an internal DNS server.

This year I had the objective to have a working FRS client. For those who are not too familiar with all the AD technologies, FRS stands for File Replication Protocol. It's one of the options to replicate shares and up to Windows 2008 it was the only option to replicate the sysvol and netlogon share for domain controllers. So in the Samba-Team and in the Samba community we are pretty interested to have this working therefor I decided to work on it. I was quite decided to work on this as much as I could during the lab.

It has turned out not to be the case, mostly because we had the opportunity to test Samba's Active Directory implementation against a couple of test suites, among them netlogon and drs. Although we have our own test suites in the Samba project to avoid regression and check the correct behavior of our products, testing against other test suites can shed light on bugs that we have. And guess what ? we have found some of them during this week but not too much, for sure fixing some flags not correctly set is not as sexy as shiny new features but having a really stable AD implementation is also a good feature and in any case other team members who participated to this event have worked on new features like multi-domain forest or DNS updates for our internal DNS server so we had a week a very studious week.

I'm now waiting for the next one !

Thursday 3 September 2009

DDNS with Windows and Samba4

I recently tried Dynamic DNS updates (aka DDNS) with Windows XP (but that's valid for anything newer) and Samba4. Globaly the explaination that comes with Samba4 are good but I noted a few points that need to be tweaked (or checked at least) to be sure that it works.

Activate signed DDNS updates

Once you configured the bind server accordingly with the documentation, it will only accept signed updates. On my test systems it turns out that XP didn't send signed updates by default.

To change this you have two choices:

  • Use GPO
  • Use local policy editor, this choice is not recommended as the modification has to be done on every workstation in the domain but for testing it's just fine !

To change the DDNS parameters you have to go in Computer Configuration -> Administrative templates -> Network -> DNS Client, if the choice is not present it's mostly likely that you miss the needed adm file (system.adm) they can be found here

Then enable Dynamic Update and Update Security Level (set the latter to Only Secure or Unsecure followed by Secure) select also Register PTR Records if you want PTR record as well. If you choose the GPO way you have to wait for the workstation to update its policy (well you can help it with gpupdate /force).

Configure correctly the reverse zone

Check the SOA record of your reverse zone, the primary name server must be valid an point to your DNS server (the DNS server is the name just after SOA in the record). To check use dig on any ip address of your zone (here my range is 10.6.1.0/24 with the dns server at 10.6.1.1) :dig 1.1.6.10.in-addr.arpa. SOA @10.6.1.1

You should get something similar to this

; <<>> DiG 9.5.1-P2 <<>> 1.1.6.10.in-addr.arpa. SOA @10.6.1.1
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4956
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;1.1.6.10.in-addr.arpa.         IN      SOA

;; AUTHORITY SECTION:
1.6.10.in-addr.arpa.    604800  IN      SOA     test.smb4.tst. root.localhost. 2009090320 172800 14400 3628800 604800

;; Query time: 2 msec
;; SERVER: 10.6.1.1#53(10.6.1.1)
;; WHEN: Thu Sep  3 19:07:17 2009
;; MSG SIZE  rcvd: 103

Test, test and test

The easiest way to test is to use ipconfig like this ipconfig /registerdns, it will force a Windows to update its DNS records in the DNS server.

Note: This KB from Microsoft explains quite well what are the option for the DNS client in case that you had specials constraints.