Hi all. I have the following setup: 1st dc is on CentOS 6 with Sernet samba 4.1.13 2nd dc is on Debian 7 with Sernet samba 4.1.13 The 2 dc work as expected. on CentOS I was able to configure sssd to work on Debian I'm using winbind Now I have a 3rd server which is CentOS 7 with samba 4.1.1 from CentOS repository. This system serves as a file server and works ok with samba, but I have a few other services (ftp, ssh) which rely on sssd 1.11.2 I dumped the krb key file from the 1st dc but with the name of the file server (as CentOS 7 does not have samba-tool command), then copied it over. (command is "samba-tool domain exportkeytab krb5.sssd.keytab --principal=$fileserver" ) sssd on this last server is working for a few days, then it stops autenticating system users (ftp, ssh, etc) In the logs I get : [sssd[ldap_child[1179]]]: Failed to initialize credentials using keytab [/etc/sssd/krb5.sssd.keytab]: Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection. [sssd[ldap_child[1179]]]: Preauthentication failed Even if I restart the service things don't change. The only solution I have found so far is regenerating the keytab file. It seems that the kerberos principal expires. Is this normal? Funny thing is that on the 1st dc I am using sssd too and ssh logins work as expected (no need to change the keytab file). Anyone seen this before? Thanks for your help. Alessandro
On 29/12/14 17:29, Alessandro Briosi wrote:> Hi all. > I have the following setup: > > 1st dc is on CentOS 6 with Sernet samba 4.1.13 > 2nd dc is on Debian 7 with Sernet samba 4.1.13 > > The 2 dc work as expected. > > on CentOS I was able to configure sssd to work > on Debian I'm using winbind > > Now I have a 3rd server which is CentOS 7 with samba 4.1.1 from CentOS > repository. > > This system serves as a file server and works ok with samba, but I > have a few other services (ftp, ssh) which rely on sssd 1.11.2 > > I dumped the krb key file from the 1st dc but with the name of the > file server (as CentOS 7 does not have samba-tool command), then > copied it over. (command is "samba-tool domain exportkeytab > krb5.sssd.keytab --principal=$fileserver" ) > > sssd on this last server is working for a few days, then it stops > autenticating system users (ftp, ssh, etc) > In the logs I get : > [sssd[ldap_child[1179]]]: Failed to initialize credentials using > keytab [/etc/sssd/krb5.sssd.keytab]: Preauthentication failed. Unable > to create GSSAPI-encrypted LDAP connection. > [sssd[ldap_child[1179]]]: Preauthentication failed > > Even if I restart the service things don't change. The only solution I > have found so far is regenerating the keytab file. > It seems that the kerberos principal expires. Is this normal? > Funny thing is that on the 1st dc I am using sssd too and ssh logins > work as expected (no need to change the keytab file). > > Anyone seen this before? > > Thanks for your help. > AlessandroHi, how have you setup the fileserver ? Is it joined to the domain ? Can you post your fileservers smb.conf Rowland
>> Even if I restart the service things don't change. The only solution I >> have found so far is regenerating the keytab file. >> It seems that the kerberos principal expires. Is this normal? >> Funny thing is that on the 1st dc I am using sssd too and ssh logins >> work as expected (no need to change the keytab file). >> >> Anyone seen this before?Which pricipal expires? That tickets expire is built into Kerberos. I'm using nslcd and require k5start to refresh the principal. Could it be that you're runnining something like that on your 1st DC? Regards, - lars.
>> Hi, how have you setup the fileserver ? >> Is it joined to the domain ? >> Can you post your fileservers smb.conf>> RowlandOT: Oops, wasn't subscribed to the mailing list :) Yes, server is joined to the domain (otherwise I would not be able to generate the principal) Server configuration is following (only global part), winbind config is there because it was used before sssd (I had troubles with library paths on CentOS 7 and sssd) [global] workgroup = DOMAIN realm = AD.DOMAIN.NET security = ads idmap config * : range = 16777216-33554431 template shell = /sbin/nologin kerberos method = secrets only netbios name = srvfile1 netbios aliases = srvfile reset on zero vc = yes server string encrypt passwords = yes load printers = no printing = bsd printcap name = /dev/null disable spoolss = yes idmap config *:backend = tdb idmap config *:range = 10000-20000 idmap config DOMAIN:backend = ad idamp config DOMAIN:schema_mode = rfc2307 idmap config DOMAIN:range = 0-40000 winbind nss info = rfc2307 winbind trusted domains only = no winbind use default domain = yes winbind enum users = yes winbind enum groups = yes winbind offline logon = false vfs objects = acl_xattr map acl inherit = Yes store dos attributes = Yes create mask = 0770
>> Even if I restart the service things don't change. The only solution I >> have found so far is regenerating the keytab file. >> It seems that the kerberos principal expires. Is this normal? >> Funny thing is that on the 1st dc I am using sssd too and ssh logins >> work as expected (no need to change the keytab file). >> >> Anyone seen this before?> Which pricipal expires? > > That tickets expire is built into Kerberos. I'm using nslcd and require > k5start to refresh the principal. Could it be that you're runnining > something like that on your 1st DC?> Regards, > - lars.That's what I was asking, is it really expiring? Should the principal be refreshed, or is there a way to make it not expire? I have followed the wiki [1], but there's no mention about principal expiration. Also the first dc (CentOS 6) is using sssd and it's principal seems to be working fine, no expiration. Thanks, Alessandro [1] https://wiki.samba.org/index.php/Local_user_management_and_authentication/sssd
Hi, The short answer to this is that Samba changes the machine account password every 7 days with the default settings. As you were told, if you join the domain with "kerberos method = secrets and keytab" on you smb.conf, the generated keytab won't expire. Another workaround would be to set "machine password timeout = 0" Best regards. On Mon, Dec 29, 2014 at 2:29 PM, Alessandro Briosi <tsdogs at briosix.org> wrote:> Hi all. > I have the following setup: > > 1st dc is on CentOS 6 with Sernet samba 4.1.13 > 2nd dc is on Debian 7 with Sernet samba 4.1.13 > > The 2 dc work as expected. > > on CentOS I was able to configure sssd to work > on Debian I'm using winbind > > Now I have a 3rd server which is CentOS 7 with samba 4.1.1 from CentOS > repository. > > This system serves as a file server and works ok with samba, but I have a > few other services (ftp, ssh) which rely on sssd 1.11.2 > > I dumped the krb key file from the 1st dc but with the name of the file > server (as CentOS 7 does not have samba-tool command), then copied it over. > (command is "samba-tool domain exportkeytab krb5.sssd.keytab > --principal=$fileserver" ) > > sssd on this last server is working for a few days, then it stops > autenticating system users (ftp, ssh, etc) > In the logs I get : > [sssd[ldap_child[1179]]]: Failed to initialize credentials using keytab > [/etc/sssd/krb5.sssd.keytab]: Preauthentication failed. Unable to create > GSSAPI-encrypted LDAP connection. > [sssd[ldap_child[1179]]]: Preauthentication failed > > Even if I restart the service things don't change. The only solution I > have found so far is regenerating the keytab file. > It seems that the kerberos principal expires. Is this normal? > Funny thing is that on the 1st dc I am using sssd too and ssh logins work > as expected (no need to change the keytab file). > > Anyone seen this before? > > Thanks for your help. > Alessandro > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >
Il 2015-01-01 22:04 George ha scritto:> Hi, > > The short answer to this is that Samba changes the machine account > password > every 7 days with the default settings. > > As you were told, if you join the domain with "kerberos method = > secrets > and keytab" on you smb.conf, the generated keytab won't expire. > > Another workaround would be to set "machine password timeout = 0" > > Best regards. >Thank you, this clarifies what it's happening. Ciao. Alessandro