Bug 866570

Summary: net ads join improperly lists realm in lowercase
Product: Red Hat Enterprise Linux 6 Reporter: Brian Harrington <bharrington>
Component: sambaAssignee: Andreas Schneider <asn>
Status: CLOSED ERRATA QA Contact: qe-baseos-daemons
Severity: low Docs Contact:
Priority: low    
Version: 6.3CC: azelinka, fharshav, gdeschner, kburres
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: samba-3.6.8-140.el6 Doc Type: Bug Fix
Doc Text:
Cause: 'net ads join' prints a wrong message. Consequence: A user might get the wrong impression about the domain join and might use the printed realm which is lowercase. Fix: We fixed the wording of the message printed about a domain join. Result: The user is correctly informed to which dns domain he joined the machine too.
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-21 08:45:35 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:

Description Brian Harrington 2012-10-15 15:59:04 UTC
Description of problem:

The utility net within the package samba-common improperly displays the realm which it has joined in all lowercase letters.  This is clearly not the realm that was joined and could cause confusion to users not familiar with kerberos.


Version-Release number of selected component (if applicable):
samba-common-3.5.10-125.el6

How reproducible:
100%

Steps to Reproduce:
1. net ads join 
2. ...
3. profit
  
Actual results:

[/usr/bin/net join -w EXAMPLE  -U sa-ldapquery_linux]
Enter sa-ldapquery_linux's password:<...>

Using short domain name -- EXAMPLE
Joined 'SERVER' to realm 'example.com'


Expected results:

[/usr/bin/net join -w EXAMPLE  -U sa-ldapquery_linux]
Enter sa-ldapquery_linux's password:<...>

Using short domain name -- EXAMPLE
Joined 'SERVER' to realm 'EXAMPLE.COM'

Comment 2 Andreas Schneider 2012-10-16 09:55:33 UTC
Can you please post your smb.conf by calling 'testparm' in the commandline and posting the output.

Comment 3 Brian Harrington 2012-10-17 19:01:35 UTC
[global]
        workgroup = EXAMPLE
        realm = EXAMPLE.COM
        server string = Samba Server Version %v
        security = ADS
        log file = /var/log/samba/log.%m
        max log size = 50
        idmap uid = 10000000-19999999
        idmap gid = 10000000-19999999
        template homedir = /home/%U
        template shell = /bin/bash
        winbind use default domain = Yes
        winbind nss info = rfc2307
        idmap config EXAMPLE: schema_mode = rfc2307
        idmap config EXAMPLE: range = 10000-9999999
        idmap config EXAMPLE: backend = ad
        cups options = raw

[homes]
        comment = Home Directories
        read only = No
        browseable = No

[printers]
        comment = All Printers
        path = /var/spool/samba
        printable = Yes
        browseable = No

Comment 4 Brian Harrington 2012-10-17 19:03:39 UTC
A copy of this bug is also being tracked internally (against a customer issue) as Issue Tracker: 00721653

Comment 5 Andreas Schneider 2012-10-18 10:34:52 UTC
The code for this message looks like this:

        if (r->out.dns_domain_name) {
                d_printf(_("Joined '%s' to realm '%s'\n"), r->in.machine_name,
                        r->out.dns_domain_name);
        }

which means that the name displayed as the realm is the DNS name sent back by the Active Directory server. It looks absolutely correct.

Comment 6 Brian Harrington 2012-10-18 14:02:38 UTC
While I understand this, it is not correct.  As per RFC 4120 (Section 6.1) - 

"Kerberos realm names are case sensitive.  Realm names that differ only in the case of the characters are not equivalent."

In this case, our realm is corresponding to the common convention that realm names should be in all uppercase.  While I understand that doing a DNS request for the name displays it differently, this is not the actual realm name.

Comment 7 Andreas Schneider 2012-10-23 15:03:37 UTC
We should replace 'realm' with 'domain' to not confuse the user.

Comment 9 Andreas Schneider 2012-10-23 16:14:05 UTC
Brian: Remember that the Kerberos realm are not case sensitive on Windows. 

However we have a patch which changes 'realm' to 'dns domain'.

Comment 10 Andreas Schneider 2012-10-23 18:26:40 UTC
*** Bug 866686 has been marked as a duplicate of this bug. ***

Comment 11 Brian Harrington 2012-10-24 00:59:30 UTC
I'm fine with the change from calling it realm to dns domain, but nonetheless a Kerberos realm is always case sensitive (even in the case of Active Directory):

From http://technet.microsoft.com/en-us/library/bb463167.aspx -

"Kerberos is case sensitive. Problems can occur in an environment using host names with mixed case. In the world of Kerberos, appserver1.EXAMPLE.COM and appserver1.example.com are not the same. Check that DNS resolves host names with consistent case."

and

"To access Kerberized services, the client computer must be capable of resolving the DNS domain of the target computer to the correct Kerberos REALM. This becomes an issue when the DNS domain name does not match the Kerberos REALM name. Because mapping does not become an issue until the client computer tries to access a service, domain to REALM mapping problems do not affect initial ticket requests (TGTs). When mapping problems exist, service ticket requests may fail or access to Kerberized services may fail. With Active Directory, the REALM name is always the uppercase equivalent of the DNS domain name."

Within Active Directory the domain name, workgroup, and accounts are not case sensitive, but the Kerberos realm still is.  This can be verified in gss5krb.dll.  In most of the Microsoft UI elements they are displaying the case insensitive domain name or workgroup, not the Kerberos realm.  This is exacerbated by the fact that the workgroup can be changed from the default of domain name minus TLD (an example was referenced in BZ 866686, which is related to the IT ticket filed for this same customer).

Comment 15 errata-xmlrpc 2013-02-21 08:45:35 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0338.html