Red Hat Bugzilla – Bug 966148
Cannot rely on MSCLDAP or _msdcs.domain.name record as indication of Active Directory
Last modified: 2013-06-05 22:25:09 EDT
It turns out that in FreeIPA with the AD trusts feature they've implemented there, that the FreeIPA server configures _msdcs DNS records, and also responds to MSCLDAP queries.
So it smells like an Active Directory server without actually implementing being able to do a join via LDAP in the same way as Active Directory.
This means we need to change our realmd discovery logic.
Pointed out by Simo.
In addition Simo suggests that using MSCLDAP is unreliable as a discovery mechanism as it may be blocked by firewalls.
Active Directory servers contain the following attribute in their RootDSE:
As described here: http://www.alvestrand.no/objectid/1.2.840.1135220.127.116.110.html
Hopefully FreeIPA won't add this attribute to their RootDSE any time soon.
Further research is necessary to determine whether Samba also has this supportedCapabilities attribute in Samba 4 AD server.
Adding Sumit or Alexander to CC list to advise if 1.2.840.113518.104.22.1680 is the way to go.
Yes, I think this is a good indicator. There is http://msdn.microsoft.com/en-us/library/cc223359.aspx which also list other capabilities which might help to detect a specific version of AD if necessary.
I wonder if we should add similar entries to the RootDSE of the IPA LDAP server to allow easy detection of an IPA server?
(In reply to Sumit Bose from comment #3)
> Yes, I think this is a good indicator. There is
> http://msdn.microsoft.com/en-us/library/cc223359.aspx which also list other
> capabilities which might help to detect a specific version of AD if
So what I think I'm going to do:
* Connect anonymous to TCP LDAP
* If supportedCapabilities: 1.2.840.113522.214.171.1240 then AD
* If supportedCapabilities: 1.2.840.1135126.96.36.1990 then Windows 2003+
* Do Netlogon lookup via TCP (since we're already connected)
which gives us domain and workgroup
* Else, prior to Windows 2003+
* Do Netlogon lookup via UDP (less reliable, but all that's available)
which gives us domain and workgroup
* Else, not AD
* Use current logic for detecting IPA via walking LDAP entries:
* Lookup default naming context for info and associatedDomain
* Lookup krbRealmContainer for kerberos realm
> I wonder if we should add similar entries to the RootDSE of the IPA LDAP
> server to allow easy detection of an IPA server?
That would be great.
Currently we parse the free form text the info: attribute of the default naming context ... which is what ipa-client does. But this is not super future proof.
Patch upstream. It's a moderately large patch. Anyone interested in looking it over?
Looks OK to me after a casual read. Just as an additional data point, in the SSSD we are also looking at the "domainControllerFunctionality" attribute. It's an integer that specifies the server version ranging from 2000 to 2012:
(In reply to Jakub Hrozek from comment #6)
> Looks OK to me after a casual read. Just as an additional data point, in the
> SSSD we are also looking at the "domainControllerFunctionality" attribute.
> It's an integer that specifies the server version ranging from 2000 to 2012:
Interesting. Looks like it does the same thing. Although we are able to lookup supportedCapabilities a little more simply.
Patch pushed upstream.
realmd-0.14.2-1.fc19 has been submitted as an update for Fedora 19.
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing realmd-0.14.2-1.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
realmd-0.14.2-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.