Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionErinn 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', 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. 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' as it would be on the command line, it failed and no UPN was created.
Comment 3Erinn 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.
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.
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 5Erinn 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
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', 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. 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' as it would be on the command line, it failed and no UPN was created.