Created attachment 8812 [details] Packet Capture If a Samba 4.0.5 DC is added to a Windows 2003 level domain with one Windows 2003 R2 DC, and RSAT Active Directory Users and Computers MMC snap-in on Windows Vista or newer is used to manage the domain, selecting the Domain Controllers OU doesn't work unless active DC is the Windows DC. While the active DC is the Samba DC, the RSAT will show the following error message, if Domain Controllers OU is clicked: "Data from Domain Controllers is not available from Domain Controller SAMBADCNAME.mydomain.site because: An operations error occurred. Try again later, or choose another DC by selecting Connect to Domain Controller on the Domain context menu." At the same time the Samba DC will log the following error: "[2013/04/17 18:03:24, 0] ../lib/ldb-samba/ldb_wrap.c:69(ldb_wrap_debug) ldb: acl_read: CN=WINDCNAME,OU=Domain Controllers,DC=mydomain,DC=site cannot find attr[msDS-isRODC] in of schema" To see discussion about this problem on samba-list, see the thread beginning with the following message: https://lists.samba.org/archive/samba/2013-April/172897.html Steps to reproduce: (0. Provision a single-DC domain with Windows 2003 R2 if necessary, or use an existing installation. Raise forest functional level to Windows 2003 native, if it is lower. Note: I'm running an external BIND 9.7.3 installation as a DNS server, but this probably doesn't matter as long as the DNS works properly.) 1. Join a Samba 4 installation to this domain as a new DC. 2. Install RSAT to a computer running Windows Vista or newer Windows. I've done most of my tests under Windows 8, but have briefly tested that this is reproducible in Vista. 3. Log on to the RSAT computer using a domain administrator account. 4. Open Active Directory Users and Computers MMC snap-in. 5. The snap-in will usually connect to the Windows DC first, as the Windows DC has operations master roles. Verify this by right-clicking the domain and choosing "Change Domain Controller". If the "Current Directory Server" is not the Windows DC, change it to that. 6. Expand the OU tree and click on the "Domain Controllers" OU. Verify that you can see all the DCs. 7. Change the active domain controller to the Samba DC using the procedure stated in step 5. 8. Expand the OU tree and click on the "Domain Controllers" OU. Acknowledge the error message and verify that an error has been written to log.samba on the Samba DC. Also see the attached packet capture (ports 88 and 389 only) taken from my RSAT computer. As I've tried to keep our actual network topology out of reach of Google & Co, I've masked the actual realm and DC names up to this point, but in the dump itself they naturally can be seen. (Our AD realm is unfortunately a public domain name, even though the DCs themselves are in a private network.) To interpret the dump, I'll give some some hints about the relevant private IPs below: 10.10.2.5 = The Windows DC 10.10.2.10 = The Samba DC (note that all the krb5 tickets are being requested from this DC) 10.10.59.46 = The RSAT-running computer The dump is taken right after purging all kerberos tickets, and involves opening the AD U & C snap-in (new krb5 tickets are being requested at this point), clicking the Domain Controllers OU to see that it works (connection is already to the Windows DC at this point), changing the active DC to be the Samba DC, expanding the tree and finally clicking the Domain Controllers OU to see that it does NOT work.
Unfortunately I can't post the krb5 keytab required to decrypt the capture here due to its sensitivity, but if a well known Samba developer asks for it, I can send it in a GPG-encrypted message. Please send me a signed message to pekka.jalkanen@vihreat.fi or add a comment here to request it.
This can be worked around by downloading a Windows 2008 R2 evaluation copy (see http://www.microsoft.com/en-us/download/details.aspx?id=11093; no actual installation required), and running the adprep commands described on the following page: http://technet.microsoft.com/en-us/library/cc731243%28v=ws.10%29.aspx This must be done _before_ promoting any Samba DCs. If Samba DCs have already been promoted, it is recommended to demote them all first, as executing the adprep commands will otherwise break replication. The very existence of this workaround also means that any meaningful reproduction of this problem must involve a Windows 2003 (perhaps R2?) domain where adprep has never been run.