[Freeipa-users] Re: Setting up fileserver using Samba shares and FreeIPA

On to, 07 kesä 2018, Kristian Petersen via FreeIPA-users wrote: > I am trying to get a file server set up using RHEL 7.5, Samba, and Red Hat > IdM 4.5.0 I have an older file server that works and hav been using it as > a template for build this new one from scratch. However, right now I > can't > get smb to start. I keep getting errors about ipasam.c in journalctl: > > Jun 06 13:53:30 fileserver1.cpms.byu.edu smbd[11624]: kerberos error: > code=-1765328203, message=Keytab contains no suitable keys for cifs/ > fileserver1.cpms.byu.edu(a)CPMS.BYU.EDU > Jun 06 13:53:31 fileserver1.cpms.byu.edu smbd[11624]: [2018/06/06 > 13:53:31.815713, 0] ipa_sam.c:4245(bind_callback_cleanup) > Jun 06 15:26:05 fileserver1.cpms.byu.edu smbd[12372]: Failed to get > base > DN. > > I have made sure that the cifs service is set up in IPA for fileserver1 > and > did an ipa-getkeytab to get a keytab for the service on fileserver1 as > well > which is why a was surprised to see a message about the keytab in the > journal. > What keytab file do you use? Please provide you smb.conf/testparm -s output. The message is very clear: it cannot find the key in the keytab file but where does it look for it? > A little earlier in the journal it also talks about being unable to do an > anonymous bind to LDAP. It doesn't surprise me that it failed, but I > tried > supplying the LDAP bind creds using smbpasswd and that didn't seem to make > any difference. It still tries an anonymous bind anyway which will never > work. > Ignore "anonymous bind" in that message. Samba's libsmbldap code checks if it has DN to bind and if not, says 'anonymous bind' in the logs. For GSSAPI authentication there is no explicit bind DN provided, thus this message. > I have also already set up a role for giving fileserver1 the permissions > necessary to allow it to read the ipaNTHash. > > P.S.: Before I sent this email to the list I upgraded one of my IPA > servers > to the new kernel in RHEL 7.5 and smb broke in what looks like the same > way > on that machine as well. It makes me wonder if this isn't a kernel > problem > rather than an IPA problem. The errors I got on that machine before > rolling back to a working snapshot are below: > > Jun 06 16:27:05 ipa1.cpms.byu.edu smbd[12179]: kerberos error: > code=-1765328360, message=Preauthentication failed > Jun 06 16:27:06 ipa1.cpms.byu.edu smbd[12179]: [2018/06/06 > 16:27:06.332266, 0] ipa_sam.c:4556(pdb_init_ipasam) > Jun 06 16:27:06 ipa1.cpms.byu.edu smbd[12179]: Failed to get base DN. > Jun 06 16:27:06 ipa1.cpms.byu.edu smbd[12179]: [2018/06/06 > 16:27:06.332318, 0] > ../source3/passdb/pdb_interface.c:180(make_pdb_method_name) > Jun 06 16:27:06 ipa1.cpms.byu.edu smbd[12179]: pdb backend > ipasam:ldapi://%2fvar%2frun%2fslapd-CPMS-BYU-EDU.socket did not correctly > init > This is, by what I can see, is an issue with a keytab here. Can you do two things below, showing output of these commands 1. - kinit admin - kvno -S cifs ipa1.cpms.byu.edu 2. - kinit -kt /path/to/cifs.keytab cifs/ipa1.cpms.byu.edu(a)CPMS.BYU.EDU - klist -k /path/to/cifs.keytab -e - klist I suspect that you messed up with kerberos keys by running ipa-getkeytab, so now you have one version of the key at the KDC side and a different one in the keytab file. And for the first part you seems to be using a totally wrong keytab file. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland