Description of problem: Client machine that joined to IPA server via realmd can not see "remote user", unless user@REALM form is used. This is not the case, when the machine binds via ipa-client-install, which is used by realmd, asfask. It would be nice if, the user names could be used without attached realm. Not sure what if that is possible with AD too, but I think should be. Version-Release number of selected component (if applicable): realmd-0.13.3-2.fc19 Steps to Reproduce: 1. join to IPA 2. this does not work $ id remoteuser 3. this works: $ id remoteuser
Currently this is by design. However I'm wondering if we can change that design. Realmd now has an option which the caller can tell realmd whether the joined to domain should 'manage' the system or not. I think that in the 'manage system' mode there is the possibility for using unqualified names. It would be expected in this case that that domain user accounts sit along side the local accounts. Jakub, so the question I have is how do we handle domain forests? Can sssd use unqualified user names for the main joined to domain, and qualified domains for the others?
I think there is a special configuration setting to assume that user is coming from the trusted domain. At least I was pushing for that and Sumit did something. Sumit would know.
By default user of the domain configured in sssd.conf, which in general is the domain you joined to either IPA or AD, can be used unqualified. All domains trusted by this domain (in sssd they are called sub-domains) must be fully qualified. I think Dmitri is looking for ticket https://fedorahosted.org/sssd/ticket/1529 . But as Stef said realmd set 'use_fully_qualified_names = True' intentionally by design. But maybe we can change the default for IPA here. I think it makes sense in the AD case because typically here the Linux host is not managed by AD. A Linux client joins an IPA domain to be manged by the IPA server. What do you think?
(In reply to comment #3) > But maybe we can change the default for IPA here. I think it makes sense in > the AD case because typically here the Linux host is not managed by AD. A > Linux client joins an IPA domain to be manged by the IPA server. What do you > think? I agree.
(In reply to comment #1) > Jakub, so the question I have is how do we handle domain forests? Can sssd > use unqualified user names for the main joined to domain, and qualified > domains for the others? As Sumit said, this is pretty much how we do it in the IPA case with the AD trusted domain. The "native" IPA users can be unqualified, while the trusted AD users have to be qualified.
When I opened the ticket I was arguing that the default should be that AD users are non-qualified and IPA users are qualified. It is a simple 80/20 case. In the case of the trust there will be 80% of the users coming from AD and 20% from IPA. IMO it should be some kind of the trust config flag in future that would be set on the server side when trusts are installed or configured. It should define how to treat IPA and AD users as qualified or not. In general we have several options and I suspect that all of them would make sense in different scenarios. Option 1: All users have to be FQ. This is probable least attractive option. Option 2: AD users a short, IPA users are FQ this is for the case when most of the users in AD Option 3: AD users are FQ, ipa users are short - this is for the case when users are in ipa domain and they need to have access to the trusted AD resources Option 4: Both are short, in this case local IPA user should probably win over the remote AD user if there is a collision though it can be controlled by a different option. I suspect that if implemented options 2 & 4 would be most popular for quite some time.
But this implies that your IPA domains already has established a trust to an AD domain or is planning to do so soon. What is with the case of a plain IPA domain? I think in this case short IPA user names are expected. For the case of IPA with a trusted AD domain, to configure sssd in a way that short names for AD user and FQ names for IPA users can be used, the name of the trusted domain must be know. So realmd has to figure out what are the trusted domains of the IPA server, if any, and then offer the users a list of options which names types the user want's to use for which domain, while with the current code only one domain can use short names. But since realmd is trying to make the domain join simple I'm not sure if this really fits here.
I am not talking about the realmd at all. So this part might be confusing. I am trying to say that may be it should be a server side configuration centrally enforced rather than the sssd configuration driven by realmd.
Patch for realmd option upstream: https://bugs.freedesktop.org/show_bug.cgi?id=60637
realmd-0.13.90-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/realmd-0.13.90-1.fc19
Package realmd-0.13.90-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.13.90-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-7111/realmd-0.13.90-1.fc19 then log in and leave karma (feedback).
realmd-0.13.91-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/realmd-0.13.91-1.fc19
This doesn't seem to work to me. Tested with: https://fedoraproject.org/wiki/QA:Testcase_realmd_join_qualify [root@fed1 ~]# cat /etc/realmd.conf [ad.example.com] fully-qualified-names = no [root@fed1 ~]# [root@fed1 ~]# systemctl restart realmd [root@fed1 ~]# [root@fed1 ~]# realm -v --user=Administrator join ad.baseos.qe * Resolving: _ldap._tcp.dc._msdcs.ad.baseos.qe * Sending MS-CLDAP ping to: 10.34.25.20 * Successfully discovered: ad.baseos.qe Password for Administrator: * Required files: /usr/sbin/sss_cache, /usr/sbin/sssd, /usr/bin/net * LANG=C LOGNAME=root /usr/bin/net -s /tmp/realmd-smb-conf.UJUMWW -U Administrator ads join ad.baseos.qe Enter Administrator's password: DNS update failed: NT_STATUS_UNSUCCESSFUL Using short domain name -- AD Joined 'FED1' to dns domain 'ad.baseos.qe' * LANG=C LOGNAME=root /usr/bin/net -s /tmp/realmd-smb-conf.UJUMWW -U Administrator ads keytab create Enter Administrator's password: * /usr/bin/systemctl enable sssd.service ln -s '/usr/lib/systemd/system/sssd.service' '/etc/systemd/system/multi-user.target.wants/sssd.service' * /usr/bin/systemctl restart sssd.service * /usr/sbin/authconfig --update --enablesssd --enablesssdauth --enablemkhomedir --nostart * Successfully enrolled machine in realm [root@fed1 ~]# [root@fed1 ~]# [root@fed1 ~]# realm list ad.baseos.qe type: kerberos realm-name: AD.BASEOS.QE domain-name: ad.baseos.qe configured: kerberos-member server-software: active-directory client-software: sssd required-package: sssd-tools required-package: sssd required-package: adcli required-package: samba-common login-formats: AD\%U login-policy: allow-realm-logins [root@fed1 ~]# [root@fed1 ~]# getent passwd Administrator [root@fed1 ~]# [root@fed1 ~]# getent passwd AD\\Administrator AD\administrator:*:1197600500:1197600513:Administrator:/home/AD/administrator:/bin/bash [root@fed1 ~]# id AD\\Administrator uid=1197600500(AD\administrator) gid=1197600513(AD\domain users) groups=1197600513(AD\domain users),1197600518(AD\schema admins),1197600519(AD\enterprise admins),1197600512(AD\domain admins),1197600520(AD\group policy creator owners),1197600572(AD\denied rodc password replication group) [root@fed1 ~]#
Do you think it's that a problem with your realmd.conf? [ad.example.com] != [ad.baseos.qe]
(In reply to comment #14) > Do you think it's that a problem with your realmd.conf? > > [ad.example.com] != [ad.baseos.qe] I hate these copy/paste bugs! Yes, my mistake, but still, it seems does not works. [root@fed1 ~]# cat /etc/realmd.conf [ad.baseos.qe] fully-qualified-names = no [root@fed1 ~]# realm -v list ad.baseos.qe type: kerberos realm-name: AD.BASEOS.QE domain-name: ad.baseos.qe configured: kerberos-member server-software: active-directory client-software: sssd required-package: sssd-tools required-package: sssd required-package: adcli required-package: samba-common login-formats: %U login-policy: allow-realm-logins [root@fed1 ~]# getent passwd Administrator [root@fed1 ~]# [root@fed1 ~]# [root@fed1 ~]# [root@fed1 ~]# getent passwd AD\\Administrator administrator:*:1197600500:1197600513:Administrator:/home/AD/administrator:/bin/bash I think you are already working on this with David, so I let it for now.
stefw advice to me commenting out the re_expression line from /etc/sssd/sssd.conf and restart sssd service. Here is results: [root@client ~]# getent passwd Administrator administrator:*:89800500:89800513:Administrator:/home/SECURITY/administrator:/bin/bash [root@client ~]# getent passwd 'SECURITY\Administrator' administrator:*:89800500:89800513:Administrator:/home/SECURITY/administrator:/bin/bash but [root@client ~]# getent passwd 'Administrator.qe' not works
(In reply to comment #15) > ... > [root@fed1 ~]# getent passwd AD\\Administrator > administrator:*:1197600500:1197600513:Administrator:/home/AD/administrator:/ > bin/bash > > > I think you are already working on this with David, so I let it for now.\ Patrik, this is probably due to realmd not restarting after changing realmd.conf (In reply to comment #16) > stefw advice to me commenting out the re_expression line from > /etc/sssd/sssd.conf and restart sssd service. > Here is results: > > [root@client ~]# getent passwd Administrator > administrator:*:89800500:89800513:Administrator:/home/SECURITY/administrator: > /bin/bash > [root@client ~]# getent passwd 'SECURITY\Administrator' > administrator:*:89800500:89800513:Administrator:/home/SECURITY/administrator: > /bin/bash > > but [root@client ~]# getent passwd 'Administrator.qe' not > works David, could you set the following lines: # comment out re_expression full_name_format = %2$s\%1$s use_fully_qualified_names = False And then run 'sss_cache --users' And then try again?
No, it still not works for me. [root@client ~]# vi /etc/sssd/sssd.conf [root@client ~]# service sssd restart Redirecting to /bin/systemctl restart sssd.service [root@client ~]# sss_cache --users [root@client ~]# getent passwd 'SECURITY\Administrator' administrator:*:89800500:89800513:Administrator:/home/SECURITY/administrator:/bin/bash [root@client ~]# getent passwd 'Administrator' administrator:*:89800500:89800513:Administrator:/home/SECURITY/administrator:/bin/bash [root@client ~]# getent passwd 'Administrator.qe' [root@client ~]# cat /etc/sssd/sssd.conf [sssd] domains = SECURITY config_file_version = 2 services = nss, pam [nss] default_shell = /bin/bash [domain/SECURITY] ad_domain = security.baseos.qe krb5_realm = SECURITY.BASEOS.QE cache_credentials = True id_provider = ad full_name_format = %2$s\%1$s krb5_store_password_if_offline = True ldap_id_mapping = True use_fully_qualified_names = False fallback_homedir = /home/%d/%u access_provider = ad
At the present time only 'Administrator@security' should work, not the full domain name. Fixing this is something the sssd guys are working on. > [root@client ~]# getent passwd 'Administrator.qe' Jakub, do you know if this has landed yet?
Yes, this works getent passwd 'Administrator@security' administrator:*:89800500:89800513:Administrator:/home/SECURITY/administrator:/bin/bash
(In reply to comment #19) > At the present time only 'Administrator@security' should work, not the full > domain name. Fixing this is something the sssd guys are working on. > > > [root@client ~]# getent passwd 'Administrator.qe' > > Jakub, do you know if this has landed yet? Actually I think it would be better to fix the issue the other way around. Currently realmd sets the SSSD domain name to the NetBIOS name of the domain. Sumit is working on a patch that would add the capability to discover the NetBIOS name dynamically, so maybe it would be better if realmd set the domain name to the same value as ad_domain and let the SSSD discover the NetBIOS name?
(In reply to comment #21) > (In reply to comment #19) > > At the present time only 'Administrator@security' should work, not the full > > domain name. Fixing this is something the sssd guys are working on. > > > > > [root@client ~]# getent passwd 'Administrator.qe' > > > > Jakub, do you know if this has landed yet? > > Actually I think it would be better to fix the issue the other way around. > > Currently realmd sets the SSSD domain name to the NetBIOS name of the > domain. Sumit is working on a patch that would add the capability to > discover the NetBIOS name dynamically, so maybe it would be better if realmd > set the domain name to the same value as ad_domain and let the SSSD discover > the NetBIOS name? For sure. Once that code is in sssd, we'll change realmd to make use of it. The current behavior is a work around because this is not yet in sssd.
(In reply to comment #17) > # comment out re_expression > full_name_format = %2$s\%1$s > use_fully_qualified_names = False Upstream commit to make things like this: http://cgit.freedesktop.org/realmd/realmd/commit/?id=83a4505c91531ad30bd79e4db2fb84f648c3a3f0
realmd-0.13.90-1.fc19 has been pushed to the Fedora 19 obsolete repository. If problems still persist, please make note of it in this bug report.