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.
Bug 987491 - Join to the second domain ovewrites the previous one
Summary: Join to the second domain ovewrites the previous one
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: realmd
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: rc
: ---
Assignee: Stef Walter
QA Contact: David Spurek
URL:
Whiteboard:
Depends On: 988207
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-23 13:44 UTC by David Spurek
Modified: 2015-03-02 05:27 UTC (History)
4 users (show)

Fixed In Version: realmd-0.14.4-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 12:52:35 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Fix up the [sssd] section in sssd.conf if it's screwed up (5.67 KB, patch)
2013-07-25 07:52 UTC, Stef Walter 		no flags Details | Diff
View All

Description David Spurek 2013-07-23 13:44:13 UTC 
Description of problem:
Join to the second domain overwrites the previous one. Set manage-system = no to AD domain: 
[security.baseos.qe]
manage-system = no

to /etc/realmd.conf. Join to this AD domain with manage-system = no, then join to IPA domain. Second join to IPA domain overwrites sssd.conf.


Version-Release number of selected component (if applicable):
realmd-0.14.2-3.el7

How reproducible:
always

Steps to Reproduce:
1. set to /etc/realmd.conf
[security.baseos.qe]
manage-system = no

2. systemctl restart realmd.service
3. realm join security.baseos.qe
4. realm join ipa.baseos.qe

Actual results:
realm list and sssd.conf contain only configuration for ipa domain

Expected results:
both domains should be listed

Additional info:
realm list and sssd.conf after first join:

[test]realm list
security.baseos.qe
  type: kerberos
  realm-name: SECURITY.BASEOS.QE
  domain-name: security.baseos.qe
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common
  login-formats: %U.qe
  login-policy: allow-permitted-logins
  permitted-logins: 
  permitted-groups: 
  domain-name: security.baseos.qe


[test]cat /etc/sssd/sssd.conf

[sssd]
domains = security.baseos.qe

[nss]
default_shell = /bin/bash

[domain/security.baseos.qe]
ad_domain = security.baseos.qe
krb5_realm = SECURITY.BASEOS.QE
realmd_tags = 
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u
simple_allow_users = $
access_provider = simple


realm join, realm list and sssd.conf after second join:

realm -v join --user=admin ipa.baseos.qe
 * Resolving: _ldap._tcp.ipa.baseos.qe
 * Performing LDAP DSE lookup on: 10.34.24.252
 * Successfully discovered: ipa.baseos.qe
Password for admin: 
 * Required files: /usr/sbin/ipa-client-install, /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd
 * LANG=C /usr/sbin/ipa-client-install --domain ipa.baseos.qe --realm IPA.BASEOS.QE --mkhomedir --enable-dns-updates --unattended --principal admin -W --force-ntpd
Discovery was successful!
Hostname: client.ipa.baseos.qe
Realm: IPA.BASEOS.QE
DNS Domain: ipa.baseos.qe
IPA Server: server.ipa.baseos.qe
BaseDN: dc=ipa,dc=baseos,dc=qe
Synchronizing time with KDC...
Successfully retrieved CA cert
    Subject:     CN=Certificate Authority,O=IPA.BASEOS.QE
    Issuer:      CN=Certificate Authority,O=IPA.BASEOS.QE
    Valid From:  Tue Apr 30 14:33:21 2013 UTC
    Valid Until: Sat Apr 30 14:33:21 2033 UTC

Enrolled in IPA realm IPA.BASEOS.QE
Created /etc/ipa/default.conf
Unable to parse existing SSSD config. As option --preserve-sssd was not specified, new config will override the old one.
The old /etc/sssd/sssd.conf is backed up and will be restored during uninstall.
New SSSD config will be created
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm IPA.BASEOS.QE
trying https://server.ipa.baseos.qe/ipa/xml
Forwarding 'env' to server 'https://server.ipa.baseos.qe/ipa/xml'
Hostname (client.ipa.baseos.qe) not found in DNS
DNS server record set to: client.ipa.baseos.qe -> 192.168.100.250
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub
Forwarding 'host_mod' to server 'https://server.ipa.baseos.qe/ipa/xml'
SSSD enabled
Configured /etc/openldap/ldap.conf
NTP enabled
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Client configuration complete.

 * /usr/bin/systemctl enable sssd.service
 * /usr/bin/systemctl restart sssd.service
 * /usr/bin/sh -c /usr/sbin/authconfig --update --enablesssd --enablesssdauth --enablemkhomedir --nostart && /usr/bin/systemctl enable oddjobd.service
 * Successfully enrolled machine in realm

[test]realm list
ipa.baseos.qe
  type: kerberos
  realm-name: IPA.BASEOS.QE
  domain-name: ipa.baseos.qe
  configured: kerberos-member
  server-software: freeipa
  client-software: sssd
  required-package: freeipa-client
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  login-formats: %U.qe
  login-policy: allow-realm-logins


[test]cat /etc/sssd/sssd.conf
[domain/ipa.baseos.qe]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ipa.baseos.qe
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = client.ipa.baseos.qe
chpass_provider = ipa
ipa_dyndns_update = True
ipa_server = _srv_, server.ipa.baseos.qe
ldap_tls_cacert = /etc/ipa/ca.crt
realmd_tags = manages-system
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u
[sssd]
services = nss, pam, ssh
config_file_version = 2

domains = ipa.baseos.qe
[nss]
default_shell = /bin/bash

[pam]

[sudo]

[autofs]

[ssh]

[pac]
Comment 1 David Spurek 2013-07-23 13:44:36 UTC 
results with package realmd-0.14.3-1.el7 are the same
Comment 2 David Spurek 2013-07-23 13:46:17 UTC 
Reverse order of join commands works correctly with the same realmd.conf.
Comment 3 Stef Walter 2013-07-24 07:58:20 UTC 
Could you try adding the following line to the [sssd] section after the AD join (but before the IPA join)?

config_file_version = 2
Comment 4 Stef Walter 2013-07-24 08:01:13 UTC 
By the way, this section of your /etc/sssd/sssd.conf file after the first step looks completely broken:

[sssd]
domains = security.baseos.qe

Do you know how it got there? When realmd creates a new sssd.conf it adds the following lines:

[sssd]
services = nss, pam
config_file_version = 2
Comment 5 David Spurek 2013-07-24 12:35:49 UTC 
My test environment was little broken before test case, concretly /etc/sssd/sssd.conf.

sssd.conf before the test was :

[sssd]
domains =

This causes fail with second realm join. Maybe it is not a bug due to broken configuration before the test, but it strange that both joins passes correctly, but only second domain is configure.
Comment 6 David Spurek 2013-07-24 13:00:54 UTC 
(In reply to Stef Walter from comment #3)
> Could you try adding the following line to the [sssd] section after the AD
> join (but before the IPA join)?
> 
> config_file_version = 2

adding config_file_version = 2 after first join doesn't help, because sssd couldn't be restarted with this configuration:

[test]service sssd restart
Redirecting to /bin/systemctl restart  sssd.service
Job for sssd.service failed. See 'systemctl status sssd.service' and 'journalctl -xn' for details.
[test]systemctl status sssd.service
sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled)
   Active: failed (Result: exit-code) since Wed 2013-07-24 08:57:55 EDT; 12s ago
  Process: 30881 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=4)

Jul 24 08:57:55 client.ipa.baseos.qe sssd[30881]: NSCD socket was detected and seems to be configured to cache some of the database...these.
Jul 24 08:57:55 client.ipa.baseos.qe sssd[30881]: SSSD couldn't load the configuration database [22]: Invalid argument.
Jul 24 08:57:55 client.ipa.baseos.qe systemd[1]: sssd.service: control process exited, code=exited status=4
Jul 24 08:57:55 client.ipa.baseos.qe systemd[1]: Failed to start System Security Services Daemon.
Jul 24 08:57:55 client.ipa.baseos.qe systemd[1]: Unit sssd.service entered failed state.
Comment 7 Stef Walter 2013-07-24 13:32:43 UTC 
Why does SSSD say this:

Jul 24 08:57:55 client.ipa.baseos.qe sssd[30881]: NSCD socket was detected and seems to be configured to cache some of the database...these.

Do you have NSCD running?
Comment 8 David Spurek 2013-07-25 05:46:35 UTC 
NSCD probably ran, now I am trying it on machine without NSCD, but result is the same:


1. adding config_file_version = 2 
2.

[test]service sssd restart
Redirecting to /bin/systemctl restart  sssd.service
Job for sssd.service failed. See 'systemctl status sssd.service' and 'journalctl -xn' for details.

[test]systemctl status sssd.service
sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled)
   Active: failed (Result: exit-code) since Thu 2013-07-25 01:37:49 EDT; 12s ago
  Process: 20769 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=4)

Jul 25 01:37:49 x86-64-v06.ipa.baseos.qe sssd[20769]: SSSD couldn't load the configuration database [22]: Invalid argument.
Jul 25 01:37:49 x86-64-v06.ipa.baseos.qe systemd[1]: sssd.service: control process exited, code=exited status=4
Jul 25 01:37:49 x86-64-v06.ipa.baseos.qe systemd[1]: Failed to start System Security Services Daemon.
Jul 25 01:37:49 x86-64-v06.ipa.baseos.qe systemd[1]: Unit sssd.service entered failed state.

[test]cat /etc/sssd/sssd.conf
[sssd]
domains = security.baseos.qe
config_file_version = 2

[nss]
default_shell = /bin/bash

[domain/security.baseos.qe]
ad_domain = security.baseos.qe
krb5_realm = SECURITY.BASEOS.QE
realmd_tags = 
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u
simple_allow_users = $
access_provider = simple


--------------------------
If I add 'services = nss, pam' to sssd.conf, it is restarted correctly and sssd.cond is configured correctly after second join. Something in realmd.conf is broken and creates broken sssd.conf.

Can you reproduce my issue Stef?
Comment 9 Stef Walter 2013-07-25 06:10:54 UTC 
(In reply to David Spurek from comment #8)
> If I add 'services = nss, pam' to sssd.conf, it is restarted correctly and
> sssd.cond is configured correctly after second join. Something in
> realmd.conf is broken and creates broken sssd.conf.
> 
> Can you reproduce my issue Stef?

Yes, but realmd only adds the services and config_file_version lines if the [sssd] section does not already exist. Why does that section exist without those lines?

I guess we could always add those lines, and try to repair broken sssd.conf files. But this is a losing game, because there are so many ways that an sssd.conf might be broken. 

How did it get broken?


I've also filed bug #988207, because sssd isn't being very helpful with telling us what's wrong.
Comment 10 David Spurek 2013-07-25 07:05:33 UTC 
I don't know how config file get broken, but it happend and I find this problematic test case.

Is it possible to check correctness of [sssd] section? Especially check if section contains 'services = ...' and 'config_file_version = 2' parameters?
Comment 11 Stef Walter 2013-07-25 07:52:41 UTC 
Created attachment 778105 [details]
Fix up the [sssd] section in sssd.conf if it's screwed up
Comment 12 Stef Walter 2013-08-07 08:10:01 UTC 
Attachment 778105 [details] pushed as 8b83dd8 - Fix up the [sssd] section in sssd.conf if it's screwed up
Comment 14 Ludek Smid 2014-06-13 12:52:35 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.
Note You need to log in before you can comment on or make changes to this bug.