Bug 1643814 - realmd.conf user-principal RFE and clarification
Summary: realmd.conf user-principal RFE and clarification
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: realmd
Version: 7.5
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Sumit Bose
QA Contact: sssd-qe
URL:
Whiteboard:
Depends On:
Blocks: 1747452
TreeView+ depends on / blocked
 
Reported: 2018-10-29 04:22 UTC by Erinn Looney-Triggs
Modified: 2019-11-19 12:50 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1747452 (view as bug list)
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)

Description Erinn Looney-Triggs 2018-10-29 04:22:05 UTC
Description of problem:
realmd has an option on the command line to specify user-principal when joining a system, and the principle can be inserted a la 'realm join example.com --user-principal=host/example.example.com@EXAMPLE.COM', realmd.conf also has the user-principal option, however it does not appear to allow for setting the name, it only appears to allow for 'yes'.

Further the documentation for realm states the following: 
        --user-principal=host/name@REALM
           Set the userPrincipalName field of the computer account to this
           kerberos principal. If you omit the value for this option, then a
           principal will be set in the form of host/shortname@REALM

This appears not to be true, when --user-principal is omitted and winbind/samba is used to join NO userPrincipalName is set.

The documentation for realmd.conf states the following:
       user-prinicpal
           Set the user-prinicpal to yes to create userPrincipalName
           attributes for the computer account in the realm, in the form
           host/computer@REALM

               [domain.example.com]
               user-principal = yes

This does work (though it lacks the control of being able to specify what the userPrincipalName is), however, the userPrincipalName set when using samba/winbind comes in the form of: host/COMPUTER@REALM this is to be expected if you look here: https://www.samba.org/samba/docs/current/man-html/net.8.html 
'[UPN] (ADS only) set the principalname attribute during the join. The default format is host/netbiosname@REALM.' But may not be expected by the end user who is not aware the commands are going through samba.

netbiosname is basically EXAMPLE

So in sum, I'd like to ask for an RFE to allow user-principal in realmd.conf to specify the requested userPrincipalName or yes, the documentation should probably state that when user-principal is NOT indicated in realmd.conf or on the command line (using samba) no userPrincipalName is created. 

And perhaps some clarification around the UPN created when user-principal = yes in realmd.conf is in order so users can expect host/EXAMPLE@EXAMPLE.COM. I suspect (though I have not confirmed) that adcli handles it differently so this may be tricky to document. 

Version-Release number of selected component (if applicable):
realmd-0.16.1-9.el7.x86_64

How reproducible:
create a simple realmd.conf:
[active-directory]
default-client = winbind

[users]
default-home = /home/%U

[ad.example.com]
computer-ou = OU=Foo,DC=ad,DC=example,DC=com
automatic-id-mapping = no
fully-qualified-names = no
computer-name = example
user-principal = yes

Join
Note the output of : net ads search '(&(objectClass=computer)(name=example))' specifically userPrincipalName

Leave removing the computer object
Remove the user-principal = yes line
Join
Note the output of : net ads search '(&(objectClass=computer)(name=example))' specifically userPrincipalName which should not exist in contradiction to the documentation.

I certainly tried joining with 'user-principal = host/example.example.com@EXAMPLE.COM' as it would be on the command line, it failed and no UPN was created.

Comment 3 Erinn Looney-Triggs 2018-10-29 05:08:33 UTC
And finally with 'user-principal = yes' in realmd.conf using adcli (this is on Fedora 29 for testing sake) UPN is set to host/example@EXAMPLE.COM. 

If user-principal is ommited from the command line realm join or from realmd.conf NO UPN is created, this again seems to contradict the man pages.

I suppose at a minimum consistency would be very very useful here.

Comment 4 Sumit Bose 2018-10-29 14:56:57 UTC
Hi,

thank you for the ticket. I agree the documentation of the user-principal options need some improvement. Especially there is no mention of the "default" user principal 'NETBIOSNAME$@AD.REALM' which is used by AD automatically even if there is no userPrincipalName attribute set and which is still the 'canonical' principal even if userPrincipalName is set (can be checked with kinit -C ...).


About the RFE to be able to specify the user-principal in realmd.conf as well. I agree that is good if command line argument and realmd.conf options are consistent. But I wonder how useful client specific settings are in a config file which typically contains other values which should be shared between multiple clients. Yes, there already is 'computer-name' but I wonder what your use case would be for being able to set the user principal explicitly in realmd.conf.

Comment 5 Erinn Looney-Triggs 2018-10-29 15:59:41 UTC
Honestly my reasons would be for consistency sake. I use 'computer-name' as well and I guess my expectations for realmd.conf is to do the same as the command line does, it is fine though if it doesn't.

This is mainly due to the questions asked here: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/thread/RPPIQ43IIUODZESOHNOOAFSNBN7PWV62/

adcli creates one type of UPN, samba creates another, I am just trying to build a consistent environment where I can be assured that the UPN is set to something consistent across all of my systems.

So I suppose I could pass that in on the command line, I was just expecting realmd.conf to basically do the same as the command line.

-Erinn


Note You need to log in before you can comment on or make changes to this bug.