Bug 1038757

Can you attach the output of authconfig --test ?

You have to have winbind authentication enabled in authconfig otherwise it will try to stop it.

Interesting.  So, my example of how to reproduce the problem might not be the best example then.  I was trying to come up with a simple way that didn't include all the setup of an IPA server.

Where I'm seeing the problem in practice is on an IPA server after ipa-adtrust-install and trust-add to setup a cross domain trust to AD.  Then I run authconfig to enable mkhomedir for users.  That's where I found winbindd not starting back up.

[root@rhel7-1 ~]# authconfig --test
caching is disabled
nss_files is always enabled
nss_compat is disabled
nss_db is disabled
nss_hesiod is disabled
 hesiod LHS = ""
 hesiod RHS = ""
nss_ldap is disabled
 LDAP+TLS is disabled
 LDAP server = "ldap://rhel7-1.ipa1.example.test"
 LDAP base DN = ""
nss_nis is disabled
 NIS server = ""
 NIS domain = ""
nss_nisplus is disabled
nss_winbind is disabled
 SMB workgroup = ""
 SMB servers = ""
 SMB security = "user"
 SMB realm = ""
 Winbind template shell = "/bin/false"
 SMB idmap range = "16777216-33554431"
nss_sss is enabled by default
nss_wins is disabled
nss_mdns4_minimal is disabled
DNS preference over NSS or WINS is disabled
pam_unix is always enabled
 shadow passwords are enabled
 password hashing algorithm is sha512
pam_krb5 is disabled
 krb5 realm = "IPA1.EXAMPLE.TEST"
 krb5 realm via dns is disabled
 krb5 kdc = "rhel7-1.ipa1.example.test:88"
 krb5 kdc via dns is enabled
 krb5 admin server = "rhel7-1.ipa1.example.test:749"
pam_ldap is disabled
 LDAP+TLS is disabled
 LDAP server = "ldap://rhel7-1.ipa1.example.test"
 LDAP base DN = ""
 LDAP schema = "rfc2307"
pam_pkcs11 is disabled
 use only smartcard for login is disabled
 smartcard module = ""
 smartcard removal action = ""
pam_fprintd is disabled
pam_ecryptfs is disabled
pam_winbind is disabled
 SMB workgroup = ""
 SMB servers = ""
 SMB security = "user"
 SMB realm = ""
pam_sss is enabled by default
 credential caching in SSSD is enabled
 SSSD use instead of legacy services if possible is enabled
IPAv2 is disabled
IPAv2 domain was not joined
 IPAv2 server = ""
 IPAv2 realm = ""
 IPAv2 domain = ""
pam_pwquality is enabled (try_first_pass local_users_only retry=3 authtok_type=)
pam_passwdqc is disabled ()
pam_access is disabled ()
pam_mkhomedir or pam_oddjob_mkhomedir is enabled (umask=0077)
Always authorize local users is enabled ()
Authenticate system accounts against network services is disabled


So is this a problem where IPA setup should be handling authconfig settings for winbind differently?

Thanks,
Scott

Apparently it does not use either of --enablewinbind --enablewinbindauth when calling authconfig. Then this is expected.

If authconfig was not asked to configure winbind, it should not disable it afterwards.

Authconfig is a tool that configures all the services that relate to user identity and authentication on the system - it owns the configuration. It should not be run unless you know what you're doing.

Tomas,

Then what would the best way be to enable mkhomedir functionality on an IPA server where we can't use authconfig for winbind?

Thanks,
Scott

(In reply to Tomas Mraz from comment #6)
> Authconfig is a tool that configures all the services that relate to user
> identity and authentication on the system - it owns the configuration. It
> should not be run unless you know what you're doing.
What configuration is owned by authconfig with regards to this? ipa-client-install did not ask authconfig to touch winbind-related configuration at all, therefore, authconfig has no business in unconfiguring it. 

Note that on IPA master where the above disabling of winbind happens, we never want to use winbind in PAM and NSSWITCH stacks. Instead, it is used internally by IPA for AD trust-related activity and is never asked to be controlled by authconfig. Winbind has number of operating modes and authentication is only one and not the most important one.

I think what we are witnessing here is incorrect logic in authconfig. If an authentication source was never enabled through authconfig, it should not be considered for disabling. Particular case of winbind on IPA masters is an example: winbind is used to provide trusted domains topology and identity source rather than authentication.

Tomas, could you please support this use case which is vital for IPA-AD interoperability in RHEL 7.

OK, but this will require serious changes in the logic how authconfig handles starting/restarting and enabling/disabling services.

I am not sure I will be able to finish this for RHEL-7.0, it might have to wait for RHEL-7.1.

Thanks.

In meantime my recommendation to Scott would be to pass --mkhomedir to ipa-server-install which will cause it to be passed to ipa-client-install and later to authconfig to properly enable home directory creation on logon.

Thanks guys.  I will change our test scripts as necessary.

Quick note, I just tested this out on an existing IPA server where I had winbind running (outside of authconfig):

[root@master ~]# authconfig --enablemkhomedir --updateall
Traceback (most recent call last):
  File "/usr/sbin/authconfig", line 1067, in <module>
    sys.exit(module.run())
  File "/usr/sbin/authconfig", line 662, in run
    self.writeAuthInfo()
  File "/usr/sbin/authconfig", line 633, in writeAuthInfo
    self.info.post(self.options.nostart)
  File "/usr/share/authconfig/authinfo.py", line 4357, in post
    togglefunc(nostart)
  File "/usr/share/authconfig/authinfo.py", line 4283, in toggleNisService
    if self.enableNis and self.nisDomain:
AttributeError: AuthInfo instance has no attribute 'enableNis'


Is this because I did an upgrade to an existing server?  Or I'm missing something that authconfig is looking for?

Thanks,
Scott

(In reply to Scott Poore from comment #14)
> Quick note, I just tested this out on an existing IPA server where I had

> Is this because I did an upgrade to an existing server?  Or I'm missing
> something that authconfig is looking for?

This is a typo in the variable name - unfortunately I did not found it during the testing. I'm fixing it just now. However you should not use --updateall but --update as --updateall will trigger the restarts (and in your case disabling winbind as well). I did not change the --updateall behavior only the --update one.

ok, yeah, I do see that --update worked as expected:

[root@master ~]# authconfig --enablemkhomedir --update

[root@master ~]# service winbind status
Redirecting to /bin/systemctl status  winbind.service
winbind.service - Samba Winbind Daemon
   Loaded: loaded (/usr/lib/systemd/system/winbind.service; disabled)
   Active: active (running) since Fri 2014-01-17 19:12:12 CST; 2 days ago
 Main PID: 29098 (winbindd)
   CGroup: /system.slice/winbind.service
           ├─29098 /usr/sbin/winbindd
           ├─29100 /usr/sbin/winbindd
           ├─29101 /usr/sbin/winbindd
           └─29102 /usr/sbin/winbindd

Jan 20 11:18:07 master.ipa1.example.test winbindd[29100]: GSSAPI client step 1
Jan 20 11:18:07 master.ipa1.example.test winbindd[29100]: GSSAPI client step 2
Jan 20 11:23:07 master.ipa1.example.test winbindd[29100]: GSSAPI client step 1
Jan 20 11:23:07 master.ipa1.example.test winbindd[29100]: GSSAPI client step 1
Jan 20 11:23:07 master.ipa1.example.test winbindd[29100]: GSSAPI client step 1
Jan 20 11:23:07 master.ipa1.example.test winbindd[29100]: GSSAPI client step 2
Jan 20 11:28:07 master.ipa1.example.test winbindd[29100]: GSSAPI client step 1
Jan 20 11:28:07 master.ipa1.example.test winbindd[29100]: GSSAPI client step 1
Jan 20 11:28:07 master.ipa1.example.test winbindd[29100]: GSSAPI client step 1
Jan 20 11:28:07 master.ipa1.example.test winbindd[29100]: GSSAPI client step 2

I'll look for the fixed one for updateall and can check that too when available.

thanks

That fixed the problem:

[root@master ~]# authconfig --enablemkhomedir --updateall
[root@master ~]#

Thanks!

Yes, change qe_test_coverage and clean qa whiteboard. Fix for this bug should be tested more deeper from my point of view, it may have impact on other parts of authconfig

Clearing out fields so the right group can take care of QA for this.

Thanks

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.