+++ This bug was initially created as a clone of Bug #966148 +++

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.

--- Additional comment from Stef Walter on 2013-05-22 11:26:45 EDT ---

Active Directory servers contain the following attribute in their RootDSE:

supportedCapabilities: 1.2.840.113556.1.4.800

As described here: http://www.alvestrand.no/objectid/1.2.840.113556.1.4.800.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.

--- Additional comment from Martin Kosek on 2013-05-23 02:58:21 EDT ---

Adding Sumit or Alexander to CC list to advise if 1.2.840.113556.1.4.800 is the way to go.

--- Additional comment from Sumit Bose on 2013-05-23 03:33:17 EDT ---

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?

--- Additional comment from Stef Walter on 2013-05-23 03:42:37 EDT ---

(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
> necessary.

Awesome. Thanks.

So what I think I'm going to do:

* Connect anonymous to TCP LDAP
  * If supportedCapabilities: 1.2.840.113556.1.4.800 then AD
    * If supportedCapabilities: 1.2.840.113556.1.4.1670 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.

--- Additional comment from Stef Walter on 2013-05-23 05:54:18 EDT ---

Patch upstream. It's a moderately large patch. Anyone interested in looking it over?

https://bugs.freedesktop.org/attachment.cgi?id=79696

--- Additional comment from Jakub Hrozek on 2013-05-23 06:17:00 EDT ---

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:
http://msdn.microsoft.com/en-us/library/cc223272.aspx

--- Additional comment from Stef Walter on 2013-05-23 07:07:23 EDT ---

(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:
> http://msdn.microsoft.com/en-us/library/cc223272.aspx

Interesting. Looks like it does the same thing. Although we are able to lookup supportedCapabilities a little more simply.

--- Additional comment from Stef Walter on 2013-05-24 03:56:54 EDT ---

Patch pushed upstream.