Bug 966148

Summary: Cannot rely on MSCLDAP or _msdcs.domain.name record as indication of Active Directory
Product: [Fedora] Fedora Reporter: Stef Walter <stefw>
Component: realmdAssignee: Stef Walter <stefw>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: abokovoy, dpal, dspurek, jhrozek, mkosek, pkis, sbose, ssorce, stefw, yelley
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: realmd-0.14.2-1.fc19 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 967032 (view as bug list) Environment:
Last Closed: 2013-06-06 02:25:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 966130, 966436    
Bug Blocks: 918092, 967032    

Description Stef Walter 2013-05-22 15:25:10 UTC
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.

Comment 1 Stef Walter 2013-05-22 15:26:45 UTC
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.

Comment 2 Martin Kosek 2013-05-23 06:58:21 UTC
Adding Sumit or Alexander to CC list to advise if 1.2.840.113556.1.4.800 is the way to go.

Comment 3 Sumit Bose 2013-05-23 07:33:17 UTC
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?

Comment 4 Stef Walter 2013-05-23 07:42:37 UTC
(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.

Comment 5 Stef Walter 2013-05-23 09:54:18 UTC
Patch upstream. It's a moderately large patch. Anyone interested in looking it over?

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

Comment 6 Jakub Hrozek 2013-05-23 10:17:00 UTC
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

Comment 7 Stef Walter 2013-05-23 11:07:23 UTC
(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.

Comment 8 Stef Walter 2013-05-24 07:56:54 UTC
Patch pushed upstream.

Comment 9 Fedora Update System 2013-05-27 12:07:14 UTC
realmd-0.14.2-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/realmd-0.14.2-1.fc19

Comment 10 Fedora Update System 2013-05-27 17:01:04 UTC
Package realmd-0.14.2-1.fc19:
* 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:
https://admin.fedoraproject.org/updates/FEDORA-2013-9364/realmd-0.14.2-1.fc19
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2013-06-06 02:25:09 UTC
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.