Hello,
I've been trying to get this working for several weeks now, but the kerberos tickets keep expiring after 7 days.
They just expired again today. I think I have set up everything correctly, but it still doesn't seem to work. I hope someone on this list can point me in the right direction.
Below is some more information. The machine is joined to an Active Directory realm with net ads join -k.
[root@hostname ~] cat /etc/krb5.conf
[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log
[libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d forwardable = true
[realms] # Define only if DNS lookups are not working # example.com = { # kdc = DC01 # admin_server = DC01.example.com # }
# EXAMPLE.COM = { # kdc = DC01.example.com # kdc = DC02.example.com # kdc = DC03.example.com # kdc = DC04.example.com # }
[domain_realm] # Define only if DNS lookups are not working # .brain.com = EXAMPLE.COM # example.com = EXAMPLE.COM
[root@hostname ~] cat /etc/samba/smb.conf
#removed commented lines [global] security = ads passdb backend = tdbsam realm = EXAMPLE.COM
password server = dc01.example.com dc02.example.com kerberos method = secrets and keytab client signing = yes client use spnego = yes load printers = yes cups options = raw[homes] comment = Home Directories browseable = no writable = yes
[printers] comment = All Printers path = /var/spool/samba browseable = no guest ok = no writable = no printable = yes
[root@hostname ~] cat /etc/sssd/sssd.conf
[sssd] domains = example.com config_file_version = 2 services = nss, pam, pac, sudo, autofs debug_level = 6
[nss] debug_level = 3
[pam] debug_level = 3
[sudo] debug_level = 3
[autofs] debug_level = 3
[domain/example.com] debug_level = 6
ad_domain = example.com ad_hostname = hostname.example.com krb5_realm = EXAMPLE.COM cache_credentials = True id_provider = ad auth_provider = krb5 krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = False use_fully_qualified_names = False fallback_homedir = /home/users/%u access_provider = ad
# LDAP settings
ldap_schema = rfc2307bis # Unless you know you need referrals, turn them off ldap_referrals = false # Uncomment if you need offline logins # cache_credentials = true enumerate = false
ldap_sasl_mech = GSSAPI
ldap_user_search_base = ou=Brain2HQ,dc=brain2,dc=com ldap_user_object_class = user
ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName
ldap_group_search_base = ou=Groups,dc=brain2,dc=com ldap_group_object_class = group
ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true
# sudo settings sudo_provider = ldap ldap_sudo_search_base = ou=sudoers,dc=brain2,dc=com
# autofs settings autofs_provider = ldap ldap_autofs_search_base=ou=automount,dc=brain2,dc=com ldap_autofs_map_object_class=nisMap ldap_autofs_entry_object_class=nisObject ldap_autofs_map_name=nisMapName ldap_autofs_entry_key=cn ldap_autofs_entry_value=nisMapEntry
# shell settings allowed_shells = /bin/sh,/bin/bash,/bin/zsh,/bin/fish,/bin/ksh, vetoed_shells = /bin/csh,/bin/tcsh shell_fallback = /bin/bash
# kerberos settings
# Probably required with sssd 1.8.x and newer krb5_canonicalize = false krb5_renewable_lifetime = 1d krb5_renew_interval = 60s krb5_lifetime = 1h #normally set by KDC
Kerberos tickets and logs of today:
[root@hostname ~] klist -f /var/lib/sss/db/ccache_example.com Ticket cache: FILE:/var/lib/sss/db/ccache_example.com Default principal: hostname$@example.com
Valid starting Expires Service principal 11/30/15 13:16:40 11/30/15 23:16:44 krbtgt/example.com@example.com renew until 12/07/15 13:16:40, Flags: RIA 11/30/15 13:16:44 11/30/15 23:16:44 ldap/dc02.example.com@ renew until 12/07/15 13:16:40, Flags: RAO 11/30/15 13:16:44 11/30/15 23:16:44 ldap/dc02.example.com@example.com renew until 12/07/15 13:16:40, Flags: RAO 11/30/15 13:16:44 11/30/15 23:16:44 DNS/dc01.example.com@example.com renew until 12/07/15 13:16:40, Flags: RAO [root@hostname ~] grep renew /var/log/sssd/sssd_example.com.log (Mon Nov 30 08:28:49 2015) [sssd[be[example.com]]] [renew_handler] (0x0100): Offline, disable renew timer. (Mon Nov 30 09:55:42 2015) [sssd[be[example.com]]] [renew_tgt_done] (0x0100): Successfully renewed TGT for user [John Doe]. (Mon Nov 30 10:26:42 2015) [sssd[be[example.com]]] [renew_tgt_done] (0x0100): Successfully renewed TGT for user [John Doe]. (Mon Nov 30 11:36:44 2015) [sssd[be[example.com]]] [renew_tgt_done] (0x0020): krb5_auth request failed. (Mon Nov 30 11:36:44 2015) [sssd[be[example.com]]] [renew_tgt_done] (0x0200): Giving back pam data. (Mon Nov 30 11:36:44 2015) [sssd[be[example.com]]] [renew_tgt_done] (0x0020): krb5_auth request failed. (Mon Nov 30 11:36:44 2015) [sssd[be[example.com]]] [renew_tgt_done] (0x0200): Giving back pam data. (Mon Nov 30 11:38:07 2015) [sssd[be[example.com]]] [renew_tgt_done] (0x0020): krb5_auth request failed. (Mon Nov 30 11:38:07 2015) [sssd[be[example.com]]] [renew_tgt_done] (0x0200): Giving back pam data. (Mon Nov 30 11:38:13 2015) [sssd[be[example.com]]] [renew_tgt_done] (0x0020): krb5_auth request failed. (Mon Nov 30 11:38:13 2015) [sssd[be[example.com]]] [renew_tgt_done] (0x0200): Giving back pam data. (Mon Nov 30 11:47:35 2015) [sssd[be[example.com]]] [renew_tgt_done] (0x0020): Failed to renew TGT for user [John Doe]. (Mon Nov 30 11:47:35 2015) [sssd[be[example.com]]] [renew_tgt_done] (0x0020): Failed to renew TGT for user [Lucy Doe]. (Mon Nov 30 14:16:07 2015) [sssd[be[example.com]]] [renew_handler] (0x0100): Offline, disable renew timer. (Mon Nov 30 17:19:34 2015) [sssd[be[example.com]]] [renew_handler] (0x0100): Offline, disable renew timer. (Mon Nov 30 18:20:26 2015) [sssd[be[example.com]]] [renew_handler] (0x0100): Offline, disable renew timer. (Mon Nov 30 18:21:36 2015) [sssd[be[example.com]]] [renew_handler] (0x0100): Offline, disable renew timer. (Mon Nov 30 19:11:06 2015) [sssd[be[example.com]]] [renew_handler] (0x0100): Offline, disable renew timer. (Mon Nov 30 19:26:31 2015) [sssd[be[example.com]]] [renew_handler] (0x0100): Offline, disable renew timer. (Mon Nov 30 23:30:05 2015) [sssd[be[example.com]]] [renew_handler] (0x0100): Offline, disable renew timer. (Tue Dec 1 00:16:56 2015) [sssd[be[example.com]]] [renew_handler] (0x0100): Offline, disable renew timer. (Tue Dec 1 01:18:39 2015) [sssd[be[example.com]]] [renew_handler] (0x0100): Offline, disable renew timer. (Tue Dec 1 01:32:16 2015) [sssd[be[example.com]]] [renew_handler] (0x0100): Offline, disable renew timer. (Tue Dec 1 03:22:02 2015) [sssd[be[example.com]]] [renew_handler] (0x0100): Offline, disable renew timer. (Tue Dec 1 04:34:30 2015) [sssd[be[example.com]]] [renew_handler] (0x0100): Offline, disable renew timer. (Tue Dec 1 06:27:39 2015) [sssd[be[example.com]]] [renew_handler] (0x0100): Offline, disable renew timer. (Tue Dec 1 06:38:20 2015) [sssd[be[example.com]]] [renew_handler] (0x0100): Offline, disable renew timer. (Tue Dec 1 07:34:20 2015) [sssd[be[example.com]]] [renew_handler] (0x0100): Offline, disable renew timer. (Tue Dec 1 07:56:02 2015) [sssd[be[example.com]]] [renew_handler] (0x0100): Offline, disable renew timer. (Tue Dec 1 08:33:09 2015) [sssd[be[example.com]]] [renew_handler] (0x0100): Offline, disable renew timer. (Tue Dec 1 10:40:41 2015) [sssd[be[example.com]]] [renew_handler] (0x0100): Offline, disable renew timer.
To be clear, it all works fine up to the point where the TGT ticket expires.
Kind Regards,
Andy
On Tue, 1 Dec 2015, Andy Airey wrote:
Hello,
I've been trying to get this working for several weeks now, but the kerberos tickets keep expiring after 7 days.
They just expired again today. I think I have set up everything correctly, but it still doesn't seem to work. I hope someone on this list can point me in the right direction.
Below is some more information. The machine is joined to an Active Directory realm with net ads join -k.
Isn't that entirely correct? You're getting a 12hr credential renewable for 7 days. What are you expecting sssd to do after 7 days?
Are you after something that stashes your password and does a regular kinit?
jh
Hi,
If I read the manpage http://linux.die.net/man/5/sssd-krb5 correctly, the setting krb5_renew_interval suggests that the krbtgt gets renewed.
I thought this meant that the ticket gets renewed (a new krbtgt is generated) before the 7 days come to an end. Now, 7 days after kinit, we cannot log on tp the machine anymore with our krb5 credentials.
If there is another way, please enlighten me :).
Kind Regards,
Andy
On 1 December 2015 at 13:03, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
On Tue, 1 Dec 2015, Andy Airey wrote:
Hello,
I've been trying to get this working for several weeks now, but the kerberos tickets keep expiring after 7 days.
They just expired again today. I think I have set up everything correctly, but it still doesn't seem to work. I hope someone on this list can point me in the right direction.
Below is some more information. The machine is joined to an Active Directory realm with net ads join -k.
Isn't that entirely correct? You're getting a 12hr credential renewable for 7 days. What are you expecting sssd to do after 7 days?
Are you after something that stashes your password and does a regular kinit?
jh _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On Tue, 1 Dec 2015, Andy Airey wrote:
Hi,
If I read the manpage http://linux.die.net/man/5/sssd-krb5 correctly, the setting krb5_renew_interval suggests that the krbtgt gets renewed.
I thought this meant that the ticket gets renewed (a new krbtgt is generated) before the 7 days come to an end. Now, 7 days after kinit, we cannot log on tp the machine anymore with our krb5 credentials.
It'll get renewed regularly, as the valid lifetime of your ticket will be more like 10/12 hours. Just do a kinit, then klist, and see what it tells you. You can ask for a longer life ticket, but AFAIK AD defaults to a max of 7 days. A long life ticket isn't particularly nice from a security point of view either.
If there is another way, please enlighten me :).
SSSD can renew until it can't. In your original post you showed:
"renew until 12/07/15 13:16:40"
You can renew until that point, but you're not allowed to get a credential valid after that point, so without a password you can feed to the KDC, or additional privs for the machine, you're done aren't you?
It's doing nothing more than a kinit -R as I understand it, and it's bound by the same limitations.
jh
I agree on the lifetime of 7 days, that's fine.
What I want to achieve is that I do not have to manually kinit the machine again. So that our users kan keep logging on, even after 7 days. I thought SSSD would do this for me. I cannot log in to each server everytime to make sure a new krbtgt is there ...
As per the manpage of kinit:
*-R*
requests renewal of the ticket-granting ticket. Note that an expired ticket cannot be renewed, even if the ticket is still within its renewable life.
If SSSD does a kinit -R, it should get a new krbtgt with a new expiration date that's 7 days ahead, right?
On 1 December 2015 at 13:26, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
On Tue, 1 Dec 2015, Andy Airey wrote:
Hi,
If I read the manpage http://linux.die.net/man/5/sssd-krb5 correctly, the setting krb5_renew_interval suggests that the krbtgt gets renewed.
I thought this meant that the ticket gets renewed (a new krbtgt is generated) before the 7 days come to an end. Now, 7 days after kinit, we cannot log on tp the machine anymore with our krb5 credentials.
It'll get renewed regularly, as the valid lifetime of your ticket will be more like 10/12 hours. Just do a kinit, then klist, and see what it tells you. You can ask for a longer life ticket, but AFAIK AD defaults to a max of 7 days. A long life ticket isn't particularly nice from a security point of view either.
If there is another way, please enlighten me :).
SSSD can renew until it can't. In your original post you showed:
"renew until 12/07/15 13:16:40"
You can renew until that point, but you're not allowed to get a credential valid after that point, so without a password you can feed to the KDC, or additional privs for the machine, you're done aren't you?
It's doing nothing more than a kinit -R as I understand it, and it's bound by the same limitations.
jh _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On Tue, 1 Dec 2015, Andy Airey wrote:
I agree on the lifetime of 7 days, that's fine.
What I want to achieve is that I do not have to manually kinit the machine again.
So that our users kan keep logging on, even after 7 days. I thought SSSD would do this for me. I cannot log in to each server everytime to make sure a new krbtgt is there ...
Now I'm lost. You wouldn't have to do it for the machine, because for the machine you would have joined it to the domain and generated a keytab, so would have a stored credential in /etc/krb5.keytab. This lasts indefinitely.
Renewals would only really relate to long running tasks running as a given user.
jh
On Tue, Dec 01, 2015 at 01:42:26PM +0100, Andy Airey wrote:
I agree on the lifetime of 7 days, that's fine.
What I want to achieve is that I do not have to manually kinit the machine again. So that our users kan keep logging on, even after 7 days. I thought SSSD would do this for me. I cannot log in to each server everytime to make sure a new krbtgt is there ...
As per the manpage of kinit:
*-R*
requests renewal of the ticket-granting ticket. Note that an expired ticket cannot be renewed, even if the ticket is still within its renewable life.
If SSSD does a kinit -R, it should get a new krbtgt with a new expiration date that's 7 days ahead, right?
no, there are 2 different time. One is the plain lifetime of the ticket the other is the renewable lifetime which relate to option -l and -r of kinit respectively.
$ kinit -l 100s -r 200s admin Password for admin@IPA.DEVEL:
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:03:41 01.12.2015 14:05:19 krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
$ kinit -R
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:04:05 01.12.2015 14:05:43 krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
As you can see the Expires time changes after 'kinit -R' but not the 'renew until' time.
HTH
bye, Sumit
On 1 December 2015 at 13:26, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
On Tue, 1 Dec 2015, Andy Airey wrote:
Hi,
If I read the manpage http://linux.die.net/man/5/sssd-krb5 correctly, the setting krb5_renew_interval suggests that the krbtgt gets renewed.
I thought this meant that the ticket gets renewed (a new krbtgt is generated) before the 7 days come to an end. Now, 7 days after kinit, we cannot log on tp the machine anymore with our krb5 credentials.
It'll get renewed regularly, as the valid lifetime of your ticket will be more like 10/12 hours. Just do a kinit, then klist, and see what it tells you. You can ask for a longer life ticket, but AFAIK AD defaults to a max of 7 days. A long life ticket isn't particularly nice from a security point of view either.
If there is another way, please enlighten me :).
SSSD can renew until it can't. In your original post you showed:
"renew until 12/07/15 13:16:40"
You can renew until that point, but you're not allowed to get a credential valid after that point, so without a password you can feed to the KDC, or additional privs for the machine, you're done aren't you?
It's doing nothing more than a kinit -R as I understand it, and it's bound by the same limitations.
jh _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
Yes - I would only add one thing - if you are unhappy with the 7 days limit, you can change default KDC settings in the domain policy for your AD (which defaults to 7 days). I have changed it to 14 days for example. O.
-----Original Message----- From: Sumit Bose [mailto:sbose@redhat.com] Sent: Tuesday, December 01, 2015 2:08 PM To: End-user discussions about the System Security Services Daemon sssd-users@lists.fedorahosted.org Subject: [SSSD-users]Re: Kerberos ticket renewal with AD
On Tue, Dec 01, 2015 at 01:42:26PM +0100, Andy Airey wrote:
I agree on the lifetime of 7 days, that's fine.
What I want to achieve is that I do not have to manually kinit the machine again. So that our users kan keep logging on, even after 7 days. I thought SSSD would do this for me. I cannot log in to each server everytime to make sure a new krbtgt is there ...
As per the manpage of kinit:
*-R*
requests renewal of the ticket-granting ticket. Note that an expired ticket cannot be renewed, even if the ticket is still within its renewable life.
If SSSD does a kinit -R, it should get a new krbtgt with a new expiration date that's 7 days ahead, right?
no, there are 2 different time. One is the plain lifetime of the ticket the other is the renewable lifetime which relate to option -l and -r of kinit respectively.
$ kinit -l 100s -r 200s admin Password for admin@IPA.DEVEL:
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:03:41 01.12.2015 14:05:19 krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
$ kinit -R
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:04:05 01.12.2015 14:05:43 krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
As you can see the Expires time changes after 'kinit -R' but not the 'renew until' time.
HTH
bye, Sumit
On 1 December 2015 at 13:26, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
On Tue, 1 Dec 2015, Andy Airey wrote:
Hi,
If I read the manpage http://linux.die.net/man/5/sssd-krb5 correctly, the setting krb5_renew_interval suggests that the krbtgt gets renewed.
I thought this meant that the ticket gets renewed (a new krbtgt is generated) before the 7 days come to an end. Now, 7 days after kinit, we cannot log on tp the machine anymore with our krb5 credentials.
It'll get renewed regularly, as the valid lifetime of your ticket will be more like 10/12 hours. Just do a kinit, then klist, and see what it tells you. You can ask for a longer life ticket, but AFAIK AD defaults to a max of 7 days. A long life ticket isn't particularly nice from a security point of view either.
If there is another way, please enlighten me :).
SSSD can renew until it can't. In your original post you showed:
"renew until 12/07/15 13:16:40"
You can renew until that point, but you're not allowed to get a credential valid after that point, so without a password you can feed to the KDC, or additional privs for the machine, you're done aren't you?
It's doing nothing more than a kinit -R as I understand it, and it's bound by the same limitations.
jh _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedoraho sted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahost ed.org
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org -----
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.
I don't mind the limit as such. I'm just looking to see how I can keep the machine joined to the domain and be able to login after said limit/renewable_lifetime.
On 1 December 2015 at 14:11, Ondrej Valousek Ondrej.Valousek@s3group.com wrote:
Yes - I would only add one thing - if you are unhappy with the 7 days limit, you can change default KDC settings in the domain policy for your AD (which defaults to 7 days). I have changed it to 14 days for example. O.
-----Original Message----- From: Sumit Bose [mailto:sbose@redhat.com] Sent: Tuesday, December 01, 2015 2:08 PM To: End-user discussions about the System Security Services Daemon < sssd-users@lists.fedorahosted.org> Subject: [SSSD-users]Re: Kerberos ticket renewal with AD
On Tue, Dec 01, 2015 at 01:42:26PM +0100, Andy Airey wrote:
I agree on the lifetime of 7 days, that's fine.
What I want to achieve is that I do not have to manually kinit the machine again. So that our users kan keep logging on, even after 7 days. I thought SSSD would do this for me. I cannot log in to each server everytime to make sure a new krbtgt is there ...
As per the manpage of kinit:
*-R*
requests renewal of the ticket-granting ticket. Note that an expired ticket cannot be renewed, even if the ticket is still within its renewable life.
If SSSD does a kinit -R, it should get a new krbtgt with a new expiration date that's 7 days ahead, right?
no, there are 2 different time. One is the plain lifetime of the ticket the other is the renewable lifetime which relate to option -l and -r of kinit respectively.
$ kinit -l 100s -r 200s admin Password for admin@IPA.DEVEL:
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:03:41 01.12.2015 14:05:19 krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
$ kinit -R
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:04:05 01.12.2015 14:05:43 krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
As you can see the Expires time changes after 'kinit -R' but not the 'renew until' time.
HTH
bye, Sumit
On 1 December 2015 at 13:26, John Hodrien J.H.Hodrien@leeds.ac.uk
wrote:
On Tue, 1 Dec 2015, Andy Airey wrote:
Hi,
If I read the manpage http://linux.die.net/man/5/sssd-krb5 correctly, the setting krb5_renew_interval suggests that the krbtgt gets renewed.
I thought this meant that the ticket gets renewed (a new krbtgt is generated) before the 7 days come to an end. Now, 7 days after kinit, we cannot log on tp the machine anymore with our krb5 credentials.
It'll get renewed regularly, as the valid lifetime of your ticket will be more like 10/12 hours. Just do a kinit, then klist, and see what it tells you. You can ask for a longer life ticket, but AFAIK AD defaults to a max of 7 days. A long life ticket isn't particularly nice from a security point of view either.
If there is another way, please enlighten me :).
SSSD can renew until it can't. In your original post you showed:
"renew until 12/07/15 13:16:40"
You can renew until that point, but you're not allowed to get a credential valid after that point, so without a password you can feed to the KDC, or additional privs for the machine, you're done
aren't you?
It's doing nothing more than a kinit -R as I understand it, and it's bound by the same limitations.
jh _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedoraho sted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahost ed.org
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
I do not understand. When you log in, you type your password -> a fresh TGT is generated every time. O.
From: Andy Airey [mailto:airey.andy@gmail.com] Sent: Tuesday, December 01, 2015 2:59 PM To: End-user discussions about the System Security Services Daemon sssd-users@lists.fedorahosted.org Subject: [SSSD-users]Re: Kerberos ticket renewal with AD
I don't mind the limit as such. I'm just looking to see how I can keep the machine joined to the domain and be able to login after said limit/renewable_lifetime.
On 1 December 2015 at 14:11, Ondrej Valousek <Ondrej.Valousek@s3group.commailto:Ondrej.Valousek@s3group.com> wrote: Yes - I would only add one thing - if you are unhappy with the 7 days limit, you can change default KDC settings in the domain policy for your AD (which defaults to 7 days). I have changed it to 14 days for example. O.
-----Original Message----- From: Sumit Bose [mailto:sbose@redhat.commailto:sbose@redhat.com] Sent: Tuesday, December 01, 2015 2:08 PM To: End-user discussions about the System Security Services Daemon <sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org> Subject: [SSSD-users]Re: Kerberos ticket renewal with AD
On Tue, Dec 01, 2015 at 01:42:26PM +0100, Andy Airey wrote:
I agree on the lifetime of 7 days, that's fine.
What I want to achieve is that I do not have to manually kinit the machine again. So that our users kan keep logging on, even after 7 days. I thought SSSD would do this for me. I cannot log in to each server everytime to make sure a new krbtgt is there ...
As per the manpage of kinit:
*-R*
requests renewal of the ticket-granting ticket. Note that an expired ticket cannot be renewed, even if the ticket is still within its renewable life.
If SSSD does a kinit -R, it should get a new krbtgt with a new expiration date that's 7 days ahead, right?
no, there are 2 different time. One is the plain lifetime of the ticket the other is the renewable lifetime which relate to option -l and -r of kinit respectively.
$ kinit -l 100s -r 200s admin Password for admin@IPA.DEVELmailto:admin@IPA.DEVEL:
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVELmailto:admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:03:41 01.12.2015 14:05:19 krbtgt/IPA.DEVEL@IPA.DEVELmailto:krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
$ kinit -R
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVELmailto:admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:04:05 01.12.2015 14:05:43 krbtgt/IPA.DEVEL@IPA.DEVELmailto:krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
As you can see the Expires time changes after 'kinit -R' but not the 'renew until' time.
HTH
bye, Sumit
On 1 December 2015 at 13:26, John Hodrien <J.H.Hodrien@leeds.ac.ukmailto:J.H.Hodrien@leeds.ac.uk> wrote:
On Tue, 1 Dec 2015, Andy Airey wrote:
Hi,
If I read the manpage http://linux.die.net/man/5/sssd-krb5 correctly, the setting krb5_renew_interval suggests that the krbtgt gets renewed.
I thought this meant that the ticket gets renewed (a new krbtgt is generated) before the 7 days come to an end. Now, 7 days after kinit, we cannot log on tp the machine anymore with our krb5 credentials.
It'll get renewed regularly, as the valid lifetime of your ticket will be more like 10/12 hours. Just do a kinit, then klist, and see what it tells you. You can ask for a longer life ticket, but AFAIK AD defaults to a max of 7 days. A long life ticket isn't particularly nice from a security point of view either.
If there is another way, please enlighten me :).
SSSD can renew until it can't. In your original post you showed:
"renew until 12/07/15 13:16:40"
You can renew until that point, but you're not allowed to get a credential valid after that point, so without a password you can feed to the KDC, or additional privs for the machine, you're done aren't you?
It's doing nothing more than a kinit -R as I understand it, and it's bound by the same limitations.
jh _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedoraho sted.orghttp://sted.org
sssd-users mailing list sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahost ed.orghttp://ed.org
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org -----
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.commailto:communications@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
-----
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.
Please check the logs in my first message.
You can see that there is a "Successfully renewed TGT" event but also a "Failed to renew TGT" event. This is before the expiration date of "11/30/15 23:16:44".
Does this mean that a new TGT is not generated when the user logs in? What if you don't log in for 7 days (unlikely, but still)?
On 1 December 2015 at 15:02, Ondrej Valousek Ondrej.Valousek@s3group.com wrote:
I do not understand.
When you log in, you type your password -> a fresh TGT is generated every time.
O.
*From:* Andy Airey [mailto:airey.andy@gmail.com] *Sent:* Tuesday, December 01, 2015 2:59 PM
*To:* End-user discussions about the System Security Services Daemon < sssd-users@lists.fedorahosted.org> *Subject:* [SSSD-users]Re: Kerberos ticket renewal with AD
I don't mind the limit as such.
I'm just looking to see how I can keep the machine joined to the domain and be able to login after said limit/renewable_lifetime.
On 1 December 2015 at 14:11, Ondrej Valousek Ondrej.Valousek@s3group.com wrote:
Yes - I would only add one thing - if you are unhappy with the 7 days limit, you can change default KDC settings in the domain policy for your AD (which defaults to 7 days). I have changed it to 14 days for example. O.
-----Original Message----- From: Sumit Bose [mailto:sbose@redhat.com] Sent: Tuesday, December 01, 2015 2:08 PM To: End-user discussions about the System Security Services Daemon < sssd-users@lists.fedorahosted.org> Subject: [SSSD-users]Re: Kerberos ticket renewal with AD
On Tue, Dec 01, 2015 at 01:42:26PM +0100, Andy Airey wrote:
I agree on the lifetime of 7 days, that's fine.
What I want to achieve is that I do not have to manually kinit the machine again. So that our users kan keep logging on, even after 7 days. I thought SSSD would do this for me. I cannot log in to each server everytime to make sure a new krbtgt is there ...
As per the manpage of kinit:
*-R*
requests renewal of the ticket-granting ticket. Note that an expired ticket cannot be renewed, even if the ticket is still within its renewable life.
If SSSD does a kinit -R, it should get a new krbtgt with a new expiration date that's 7 days ahead, right?
no, there are 2 different time. One is the plain lifetime of the ticket the other is the renewable lifetime which relate to option -l and -r of kinit respectively.
$ kinit -l 100s -r 200s admin Password for admin@IPA.DEVEL:
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:03:41 01.12.2015 14:05:19 krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
$ kinit -R
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:04:05 01.12.2015 14:05:43 krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
As you can see the Expires time changes after 'kinit -R' but not the 'renew until' time.
HTH
bye, Sumit
On 1 December 2015 at 13:26, John Hodrien J.H.Hodrien@leeds.ac.uk
wrote:
On Tue, 1 Dec 2015, Andy Airey wrote:
Hi,
If I read the manpage http://linux.die.net/man/5/sssd-krb5 correctly, the setting krb5_renew_interval suggests that the krbtgt gets renewed.
I thought this meant that the ticket gets renewed (a new krbtgt is generated) before the 7 days come to an end. Now, 7 days after kinit, we cannot log on tp the machine anymore with our krb5 credentials.
It'll get renewed regularly, as the valid lifetime of your ticket will be more like 10/12 hours. Just do a kinit, then klist, and see what it tells you. You can ask for a longer life ticket, but AFAIK AD defaults to a max of 7 days. A long life ticket isn't particularly nice from a security point of view either.
If there is another way, please enlighten me :).
SSSD can renew until it can't. In your original post you showed:
"renew until 12/07/15 13:16:40"
You can renew until that point, but you're not allowed to get a credential valid after that point, so without a password you can feed to the KDC, or additional privs for the machine, you're done
aren't you?
It's doing nothing more than a kinit -R as I understand it, and it's bound by the same limitations.
jh _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedoraho sted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahost ed.org
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
These logs are irrelevant. When you log in, a fresh TGT is generated. Every time. Messages like „Successfully renewed TGT“ appears as you keep your session open And then evetually „Failed to renew TGT“ appears“ – if you keep your session open >7 days. This does not mean you can not log in again.
O.
From: Andy Airey [mailto:airey.andy@gmail.com] Sent: Tuesday, December 01, 2015 3:08 PM To: End-user discussions about the System Security Services Daemon sssd-users@lists.fedorahosted.org Subject: [SSSD-users]Re: Kerberos ticket renewal with AD
Please check the logs in my first message. You can see that there is a "Successfully renewed TGT" event but also a "Failed to renew TGT" event. This is before the expiration date of "11/30/15 23:16:44". Does this mean that a new TGT is not generated when the user logs in? What if you don't log in for 7 days (unlikely, but still)?
On 1 December 2015 at 15:02, Ondrej Valousek <Ondrej.Valousek@s3group.commailto:Ondrej.Valousek@s3group.com> wrote: I do not understand. When you log in, you type your password -> a fresh TGT is generated every time. O.
From: Andy Airey [mailto:airey.andy@gmail.commailto:airey.andy@gmail.com] Sent: Tuesday, December 01, 2015 2:59 PM
To: End-user discussions about the System Security Services Daemon <sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org> Subject: [SSSD-users]Re: Kerberos ticket renewal with AD
I don't mind the limit as such. I'm just looking to see how I can keep the machine joined to the domain and be able to login after said limit/renewable_lifetime.
On 1 December 2015 at 14:11, Ondrej Valousek <Ondrej.Valousek@s3group.commailto:Ondrej.Valousek@s3group.com> wrote: Yes - I would only add one thing - if you are unhappy with the 7 days limit, you can change default KDC settings in the domain policy for your AD (which defaults to 7 days). I have changed it to 14 days for example. O.
-----Original Message----- From: Sumit Bose [mailto:sbose@redhat.commailto:sbose@redhat.com] Sent: Tuesday, December 01, 2015 2:08 PM To: End-user discussions about the System Security Services Daemon <sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org> Subject: [SSSD-users]Re: Kerberos ticket renewal with AD
On Tue, Dec 01, 2015 at 01:42:26PM +0100, Andy Airey wrote:
I agree on the lifetime of 7 days, that's fine.
What I want to achieve is that I do not have to manually kinit the machine again. So that our users kan keep logging on, even after 7 days. I thought SSSD would do this for me. I cannot log in to each server everytime to make sure a new krbtgt is there ...
As per the manpage of kinit:
*-R*
requests renewal of the ticket-granting ticket. Note that an expired ticket cannot be renewed, even if the ticket is still within its renewable life.
If SSSD does a kinit -R, it should get a new krbtgt with a new expiration date that's 7 days ahead, right?
no, there are 2 different time. One is the plain lifetime of the ticket the other is the renewable lifetime which relate to option -l and -r of kinit respectively.
$ kinit -l 100s -r 200s admin Password for admin@IPA.DEVELmailto:admin@IPA.DEVEL:
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVELmailto:admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:03:41 01.12.2015 14:05:19 krbtgt/IPA.DEVEL@IPA.DEVELmailto:krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
$ kinit -R
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVELmailto:admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:04:05 01.12.2015 14:05:43 krbtgt/IPA.DEVEL@IPA.DEVELmailto:krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
As you can see the Expires time changes after 'kinit -R' but not the 'renew until' time.
HTH
bye, Sumit
On 1 December 2015 at 13:26, John Hodrien <J.H.Hodrien@leeds.ac.ukmailto:J.H.Hodrien@leeds.ac.uk> wrote:
On Tue, 1 Dec 2015, Andy Airey wrote:
Hi,
If I read the manpage http://linux.die.net/man/5/sssd-krb5 correctly, the setting krb5_renew_interval suggests that the krbtgt gets renewed.
I thought this meant that the ticket gets renewed (a new krbtgt is generated) before the 7 days come to an end. Now, 7 days after kinit, we cannot log on tp the machine anymore with our krb5 credentials.
It'll get renewed regularly, as the valid lifetime of your ticket will be more like 10/12 hours. Just do a kinit, then klist, and see what it tells you. You can ask for a longer life ticket, but AFAIK AD defaults to a max of 7 days. A long life ticket isn't particularly nice from a security point of view either.
If there is another way, please enlighten me :).
SSSD can renew until it can't. In your original post you showed:
"renew until 12/07/15 13:16:40"
You can renew until that point, but you're not allowed to get a credential valid after that point, so without a password you can feed to the KDC, or additional privs for the machine, you're done aren't you?
It's doing nothing more than a kinit -R as I understand it, and it's bound by the same limitations.
jh _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedoraho sted.orghttp://sted.org
sssd-users mailing list sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahost ed.orghttp://ed.org
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org -----
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.commailto:communications@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
-----
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.commailto:communications@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
-----
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.
On Tue, Dec 01, 2015 at 02:59:02PM +0100, Andy Airey wrote:
I don't mind the limit as such. I'm just looking to see how I can keep the machine joined to the domain and be able to login after said limit/renewable_lifetime.
What do you mean by "keep the machine joined to the domain". I thought you were talking of TGTs for user principals.
If you want to get a fresh TGT (including a fresh renew until) for the host itself you can just use the keytab by calling
kinit -k
Can you describe your use-case in more details?
Thank you.
bye, Sumit
On 1 December 2015 at 14:11, Ondrej Valousek Ondrej.Valousek@s3group.com wrote:
Yes - I would only add one thing - if you are unhappy with the 7 days limit, you can change default KDC settings in the domain policy for your AD (which defaults to 7 days). I have changed it to 14 days for example. O.
-----Original Message----- From: Sumit Bose [mailto:sbose@redhat.com] Sent: Tuesday, December 01, 2015 2:08 PM To: End-user discussions about the System Security Services Daemon < sssd-users@lists.fedorahosted.org> Subject: [SSSD-users]Re: Kerberos ticket renewal with AD
On Tue, Dec 01, 2015 at 01:42:26PM +0100, Andy Airey wrote:
I agree on the lifetime of 7 days, that's fine.
What I want to achieve is that I do not have to manually kinit the machine again. So that our users kan keep logging on, even after 7 days. I thought SSSD would do this for me. I cannot log in to each server everytime to make sure a new krbtgt is there ...
As per the manpage of kinit:
*-R*
requests renewal of the ticket-granting ticket. Note that an expired ticket cannot be renewed, even if the ticket is still within its renewable life.
If SSSD does a kinit -R, it should get a new krbtgt with a new expiration date that's 7 days ahead, right?
no, there are 2 different time. One is the plain lifetime of the ticket the other is the renewable lifetime which relate to option -l and -r of kinit respectively.
$ kinit -l 100s -r 200s admin Password for admin@IPA.DEVEL:
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:03:41 01.12.2015 14:05:19 krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
$ kinit -R
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:04:05 01.12.2015 14:05:43 krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
As you can see the Expires time changes after 'kinit -R' but not the 'renew until' time.
HTH
bye, Sumit
On 1 December 2015 at 13:26, John Hodrien J.H.Hodrien@leeds.ac.uk
wrote:
On Tue, 1 Dec 2015, Andy Airey wrote:
Hi,
If I read the manpage http://linux.die.net/man/5/sssd-krb5 correctly, the setting krb5_renew_interval suggests that the krbtgt gets renewed.
I thought this meant that the ticket gets renewed (a new krbtgt is generated) before the 7 days come to an end. Now, 7 days after kinit, we cannot log on tp the machine anymore with our krb5 credentials.
It'll get renewed regularly, as the valid lifetime of your ticket will be more like 10/12 hours. Just do a kinit, then klist, and see what it tells you. You can ask for a longer life ticket, but AFAIK AD defaults to a max of 7 days. A long life ticket isn't particularly nice from a security point of view either.
If there is another way, please enlighten me :).
SSSD can renew until it can't. In your original post you showed:
"renew until 12/07/15 13:16:40"
You can renew until that point, but you're not allowed to get a credential valid after that point, so without a password you can feed to the KDC, or additional privs for the machine, you're done
aren't you?
It's doing nothing more than a kinit -R as I understand it, and it's bound by the same limitations.
jh _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedoraho sted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahost ed.org
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
What I am experiencing is that I can use the machine for 7 days until the TGT in SSSD's ccache expires.
With "use" I mean: - LDAP lookups with SASL-GSSAPI binds for automount maps and sudoRoles - login to the machine both with GSSAPI and password
When the ticket expires, the connection to AD is gone completely. My understanding was that, with the krb5_renew* settings, this would be resolved.
It seems like I'm getting this wrong, but is there a way to get a new TGT (with new renew until) through SSSD? Cron 'kinit -k' every week? Doesn't sound like the right way to do it.
On 1 December 2015 at 15:13, Sumit Bose sbose@redhat.com wrote:
On Tue, Dec 01, 2015 at 02:59:02PM +0100, Andy Airey wrote:
I don't mind the limit as such. I'm just looking to see how I can keep the machine joined to the domain
and
be able to login after said limit/renewable_lifetime.
What do you mean by "keep the machine joined to the domain". I thought you were talking of TGTs for user principals.
If you want to get a fresh TGT (including a fresh renew until) for the host itself you can just use the keytab by calling
kinit -k
Can you describe your use-case in more details?
Thank you.
bye, Sumit
On 1 December 2015 at 14:11, Ondrej Valousek <
Ondrej.Valousek@s3group.com>
wrote:
Yes - I would only add one thing - if you are unhappy with the 7 days limit, you can change default KDC settings in the domain policy for
your AD
(which defaults to 7 days). I have changed it to 14 days for example. O.
-----Original Message----- From: Sumit Bose [mailto:sbose@redhat.com] Sent: Tuesday, December 01, 2015 2:08 PM To: End-user discussions about the System Security Services Daemon < sssd-users@lists.fedorahosted.org> Subject: [SSSD-users]Re: Kerberos ticket renewal with AD
On Tue, Dec 01, 2015 at 01:42:26PM +0100, Andy Airey wrote:
I agree on the lifetime of 7 days, that's fine.
What I want to achieve is that I do not have to manually kinit the machine again. So that our users kan keep logging on, even after 7 days. I thought SSSD would do this for me. I cannot log in to each server everytime to make sure a new krbtgt is there ...
As per the manpage of kinit:
*-R*
requests renewal of the ticket-granting ticket. Note that an
expired
ticket cannot be renewed, even if the ticket is still within its renewable life.
If SSSD does a kinit -R, it should get a new krbtgt with a new expiration date that's 7 days ahead, right?
no, there are 2 different time. One is the plain lifetime of the ticket the other is the renewable lifetime which relate to option -l and -r of kinit respectively.
$ kinit -l 100s -r 200s admin Password for admin@IPA.DEVEL:
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:03:41 01.12.2015 14:05:19 krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
$ kinit -R
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:04:05 01.12.2015 14:05:43 krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
As you can see the Expires time changes after 'kinit -R' but not the 'renew until' time.
HTH
bye, Sumit
On 1 December 2015 at 13:26, John Hodrien J.H.Hodrien@leeds.ac.uk
wrote:
On Tue, 1 Dec 2015, Andy Airey wrote:
Hi,
If I read the manpage http://linux.die.net/man/5/sssd-krb5 correctly, the setting krb5_renew_interval suggests that the
krbtgt
gets renewed.
I thought this meant that the ticket gets renewed (a new krbtgt is generated) before the 7 days come to an end. Now, 7 days after kinit, we cannot log on tp the machine anymore with our krb5 credentials.
It'll get renewed regularly, as the valid lifetime of your ticket will be more like 10/12 hours. Just do a kinit, then klist, and
see
what it tells you. You can ask for a longer life ticket, but AFAIK AD defaults to a
max
of 7 days. A long life ticket isn't particularly nice from a security point of view either.
If there is another way, please enlighten me :).
SSSD can renew until it can't. In your original post you showed:
"renew until 12/07/15 13:16:40"
You can renew until that point, but you're not allowed to get a credential valid after that point, so without a password you can feed to the KDC, or additional privs for the machine, you're done
aren't you?
It's doing nothing more than a kinit -R as I understand it, and
it's
bound by the same limitations.
jh _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedoraho
sted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahost
ed.org
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof.
If
you have received this e-mail in error, please notify the sender by
return
e-mail and delete all copies of this e-mail from your computer
system(s).
Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered
in
Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
2015-12-01 15:30 GMT+01:00 Andy Airey airey.andy@gmail.com:
What I am experiencing is that I can use the machine for 7 days until the TGT in SSSD's ccache expires.
With "use" I mean:
- LDAP lookups with SASL-GSSAPI binds for automount maps and sudoRoles
- login to the machine both with GSSAPI and password
When the ticket expires, the connection to AD is gone completely. My understanding was that, with the krb5_renew* settings, this would be resolved.
It seems like I'm getting this wrong, but is there a way to get a new TGT (with new renew until) through SSSD? Cron 'kinit -k' every week? Doesn't sound like the right way to do it.
That's what I would do. According to previous mails the renewable date is updated only when credentials are given (sending a password or plying with a keytab). Accordigin to what you say you want to change the renewable date.
Just use your keytab to change that date, no?
On 1 December 2015 at 15:13, Sumit Bose sbose@redhat.com wrote:
On Tue, Dec 01, 2015 at 02:59:02PM +0100, Andy Airey wrote:
I don't mind the limit as such. I'm just looking to see how I can keep the machine joined to the domain
and
be able to login after said limit/renewable_lifetime.
What do you mean by "keep the machine joined to the domain". I thought you were talking of TGTs for user principals.
If you want to get a fresh TGT (including a fresh renew until) for the host itself you can just use the keytab by calling
kinit -k
Can you describe your use-case in more details?
Thank you.
bye, Sumit
On 1 December 2015 at 14:11, Ondrej Valousek <
Ondrej.Valousek@s3group.com>
wrote:
Yes - I would only add one thing - if you are unhappy with the 7 days limit, you can change default KDC settings in the domain policy for
your AD
(which defaults to 7 days). I have changed it to 14 days for example. O.
-----Original Message----- From: Sumit Bose [mailto:sbose@redhat.com] Sent: Tuesday, December 01, 2015 2:08 PM To: End-user discussions about the System Security Services Daemon < sssd-users@lists.fedorahosted.org> Subject: [SSSD-users]Re: Kerberos ticket renewal with AD
On Tue, Dec 01, 2015 at 01:42:26PM +0100, Andy Airey wrote:
I agree on the lifetime of 7 days, that's fine.
What I want to achieve is that I do not have to manually kinit the machine again. So that our users kan keep logging on, even after 7 days. I thought SSSD would do this for me. I cannot log in to each server everytime to make sure a new krbtgt is there ...
As per the manpage of kinit:
*-R*
requests renewal of the ticket-granting ticket. Note that an
expired
ticket cannot be renewed, even if the ticket is still within its renewable life.
If SSSD does a kinit -R, it should get a new krbtgt with a new expiration date that's 7 days ahead, right?
no, there are 2 different time. One is the plain lifetime of the
ticket
the other is the renewable lifetime which relate to option -l and -r
of
kinit respectively.
$ kinit -l 100s -r 200s admin Password for admin@IPA.DEVEL:
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:03:41 01.12.2015 14:05:19 krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
$ kinit -R
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:04:05 01.12.2015 14:05:43 krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
As you can see the Expires time changes after 'kinit -R' but not the 'renew until' time.
HTH
bye, Sumit
On 1 December 2015 at 13:26, John Hodrien J.H.Hodrien@leeds.ac.uk
wrote:
On Tue, 1 Dec 2015, Andy Airey wrote:
Hi, > > If I read the manpage http://linux.die.net/man/5/sssd-krb5 > correctly, the setting krb5_renew_interval suggests that the
krbtgt
> gets renewed. > > I thought this meant that the ticket gets renewed (a new krbtgt
is
> generated) before the 7 days come to an end. > Now, 7 days after kinit, we cannot log on tp the machine anymore > with our > krb5 credentials. >
It'll get renewed regularly, as the valid lifetime of your ticket will be more like 10/12 hours. Just do a kinit, then klist, and
see
what it tells you. You can ask for a longer life ticket, but AFAIK AD defaults to a
max
of 7 days. A long life ticket isn't particularly nice from a security point of view either.
If there is another way, please enlighten me :). >
SSSD can renew until it can't. In your original post you showed:
"renew until 12/07/15 13:16:40"
You can renew until that point, but you're not allowed to get a credential valid after that point, so without a password you can feed to the KDC, or additional privs for the machine, you're done
aren't you?
It's doing nothing more than a kinit -R as I understand it, and
it's
bound by the same limitations.
jh _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedoraho
sted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahost
ed.org
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the
intended
recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof.
If
you have received this e-mail in error, please notify the sender by
return
e-mail and delete all copies of this e-mail from your computer
system(s).
Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group).
Registered in
Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
I’m having this problem as well. This is only happening on Ubuntu machines for me, the RedHat and CentOS machines don’t seem to have this issue. I was starting to think this might be a problem with Kerberos libraries or something, otherwise I can’t understand why it wouldn’t work only on Ubuntu.
I monitor when one of my servers loses contact with the AD by running a cron script every 10 minutes: #!/bin/bash
HOST=`hostname` TST=`kinit -k 'SERVERNAME $@AD.MYDOMAIN.COM' 2>&1` if [ "$TST" != "" ]; then logger -p user.crit "SSSD AUTH ERROR: [$DATE] $TST on $HOST" DATE=`date` echo "[$DATE]" $TST>>/root/sssd-weirdness.txt fi
I get back: [Wed Oct 28 15:50:01 CDT 2015] kinit: Preauthentication failed while getting initial credentials, right at 7 days after the last time I manually rejoined the server. Running ‘kinit –k’ is not working for me.
From: Andy Airey [mailto:airey.andy@gmail.com] Sent: Tuesday, December 01, 2015 8:31 AM To: End-user discussions about the System Security Services Daemon sssd-users@lists.fedorahosted.org Subject: [SSSD-users]Re: Kerberos ticket renewal with AD
What I am experiencing is that I can use the machine for 7 days until the TGT in SSSD's ccache expires. With "use" I mean: - LDAP lookups with SASL-GSSAPI binds for automount maps and sudoRoles - login to the machine both with GSSAPI and password When the ticket expires, the connection to AD is gone completely. My understanding was that, with the krb5_renew* settings, this would be resolved.
It seems like I'm getting this wrong, but is there a way to get a new TGT (with new renew until) through SSSD? Cron 'kinit -k' every week? Doesn't sound like the right way to do it.
On 1 December 2015 at 15:13, Sumit Bose <sbose@redhat.commailto:sbose@redhat.com> wrote: On Tue, Dec 01, 2015 at 02:59:02PM +0100, Andy Airey wrote:
I don't mind the limit as such. I'm just looking to see how I can keep the machine joined to the domain and be able to login after said limit/renewable_lifetime.
What do you mean by "keep the machine joined to the domain". I thought you were talking of TGTs for user principals.
If you want to get a fresh TGT (including a fresh renew until) for the host itself you can just use the keytab by calling
kinit -k
Can you describe your use-case in more details?
Thank you.
bye, Sumit
On 1 December 2015 at 14:11, Ondrej Valousek <Ondrej.Valousek@s3group.commailto:Ondrej.Valousek@s3group.com> wrote:
Yes - I would only add one thing - if you are unhappy with the 7 days limit, you can change default KDC settings in the domain policy for your AD (which defaults to 7 days). I have changed it to 14 days for example. O.
-----Original Message----- From: Sumit Bose [mailto:sbose@redhat.commailto:sbose@redhat.com] Sent: Tuesday, December 01, 2015 2:08 PM To: End-user discussions about the System Security Services Daemon < sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org> Subject: [SSSD-users]Re: Kerberos ticket renewal with AD
On Tue, Dec 01, 2015 at 01:42:26PM +0100, Andy Airey wrote:
I agree on the lifetime of 7 days, that's fine.
What I want to achieve is that I do not have to manually kinit the machine again. So that our users kan keep logging on, even after 7 days. I thought SSSD would do this for me. I cannot log in to each server everytime to make sure a new krbtgt is there ...
As per the manpage of kinit:
*-R*
requests renewal of the ticket-granting ticket. Note that an expired ticket cannot be renewed, even if the ticket is still within its renewable life.
If SSSD does a kinit -R, it should get a new krbtgt with a new expiration date that's 7 days ahead, right?
no, there are 2 different time. One is the plain lifetime of the ticket the other is the renewable lifetime which relate to option -l and -r of kinit respectively.
$ kinit -l 100s -r 200s admin Password for admin@IPA.DEVELmailto:admin@IPA.DEVEL:
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVELmailto:admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:03:41 01.12.2015 14:05:19 krbtgt/IPA.DEVEL@IPA.DEVELmailto:krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
$ kinit -R
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVELmailto:admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:04:05 01.12.2015 14:05:43 krbtgt/IPA.DEVEL@IPA.DEVELmailto:krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
As you can see the Expires time changes after 'kinit -R' but not the 'renew until' time.
HTH
bye, Sumit
On 1 December 2015 at 13:26, John Hodrien <J.H.Hodrien@leeds.ac.ukmailto:J.H.Hodrien@leeds.ac.uk>
wrote:
On Tue, 1 Dec 2015, Andy Airey wrote:
Hi,
If I read the manpage <http://linux.die.net/man/5/sssd-krb5https://urldefense.proofpoint.com/v2/url?u=http-3A__linux.die.net_man_5_sssd-2Dkrb5&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=lOzDV2tBj_QUtj8shmzZozxokiQ04eZWC62NOnYeExc&s=5WaSmaVNrotMVxUWYZZaVvd6bWOAJl4jCNn7f8McQGY&e=> correctly, the setting krb5_renew_interval suggests that the krbtgt gets renewed.
I thought this meant that the ticket gets renewed (a new krbtgt is generated) before the 7 days come to an end. Now, 7 days after kinit, we cannot log on tp the machine anymore with our krb5 credentials.
It'll get renewed regularly, as the valid lifetime of your ticket will be more like 10/12 hours. Just do a kinit, then klist, and see what it tells you. You can ask for a longer life ticket, but AFAIK AD defaults to a max of 7 days. A long life ticket isn't particularly nice from a security point of view either.
If there is another way, please enlighten me :).
SSSD can renew until it can't. In your original post you showed:
"renew until 12/07/15 13:16:40"
You can renew until that point, but you're not allowed to get a credential valid after that point, so without a password you can feed to the KDC, or additional privs for the machine, you're done
aren't you?
It's doing nothing more than a kinit -R as I understand it, and it's bound by the same limitations.
jh _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahohttps://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_admin_lists_sssd-2Dusers-40lists.fedoraho&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=lOzDV2tBj_QUtj8shmzZozxokiQ04eZWC62NOnYeExc&s=CQjrLKLh5_1Y1aLJpbzHwJivH1oWgyiBqZfjWqbaE9o&e= sted.orghttps://urldefense.proofpoint.com/v2/url?u=http-3A__sted.org&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=lOzDV2tBj_QUtj8shmzZozxokiQ04eZWC62NOnYeExc&s=T9HGch8VvhHA0j4EF5QC05fNtfr6ICgR21pHm8xy2YQ&e=
sssd-users mailing list sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosthttps://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_admin_lists_sssd-2Dusers-40lists.fedorahost&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=lOzDV2tBj_QUtj8shmzZozxokiQ04eZWC62NOnYeExc&s=LkFB15cHClZB-Mq7TetP74XcBBIfDpCvNGxFlKWgrNc&e= ed.orghttps://urldefense.proofpoint.com/v2/url?u=http-3A__ed.org&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=lOzDV2tBj_QUtj8shmzZozxokiQ04eZWC62NOnYeExc&s=k0ETHgvkZiGrfta5jWtTYoXzl81bGMNRwmvwhBiooOU&e=
sssd-users mailing list sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.orghttps://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_admin_lists_sssd-2Dusers-40lists.fedorahosted.org&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=lOzDV2tBj_QUtj8shmzZozxokiQ04eZWC62NOnYeExc&s=NmfEFeJyYtbQ0hKKRzd51OfH-PRxjMkmPYxvPt6bH3w&e=
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.commailto:communications@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.orghttps://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_admin_lists_sssd-2Dusers-40lists.fedorahosted.org&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=lOzDV2tBj_QUtj8shmzZozxokiQ04eZWC62NOnYeExc&s=NmfEFeJyYtbQ0hKKRzd51OfH-PRxjMkmPYxvPt6bH3w&e=
sssd-users mailing list sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.orghttps://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_admin_lists_sssd-2Dusers-40lists.fedorahosted.org&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=lOzDV2tBj_QUtj8shmzZozxokiQ04eZWC62NOnYeExc&s=NmfEFeJyYtbQ0hKKRzd51OfH-PRxjMkmPYxvPt6bH3w&e=
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.orghttps://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_admin_lists_sssd-2Dusers-40lists.fedorahosted.org&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=lOzDV2tBj_QUtj8shmzZozxokiQ04eZWC62NOnYeExc&s=NmfEFeJyYtbQ0hKKRzd51OfH-PRxjMkmPYxvPt6bH3w&e=
On Tue, 1 Dec 2015, Thackeray, Neil L wrote:
I’m having this problem as well. This is only happening on Ubuntu machines for me, the RedHat and CentOS machines don’t seem to have this issue. I was starting to think this might be a problem with Kerberos libraries or something, otherwise I can’t understand why it wouldn’t work only on Ubuntu.
I monitor when one of my servers loses contact with the AD by running a cron script every 10 minutes: #!/bin/bash
HOST=`hostname` TST=`kinit -k 'SERVERNAME $@AD.MYDOMAIN.COM' 2>&1` if [ "$TST" != "" ]; then logger -p user.crit "SSSD AUTH ERROR: [$DATE] $TST on $HOST" DATE=`date` echo "[$DATE]" $TST>>/root/sssd-weirdness.txt fi
Have you got something in AD mandating machine password changes, or do you have something like msktutil running doing it for you?
jh
I don't control the AD, but I looked and couldn't find a policy mandating machine password changes outside of the standard time. I am not running msktutil, but I don't really see why I should have to. This is what sssd is supposed to be doing for me, and it's working just fine in CentOS and RedHat out of the box.
Neil
-----Original Message----- From: John Hodrien [mailto:J.H.Hodrien@leeds.ac.uk] Sent: Tuesday, December 01, 2015 10:13 AM To: End-user discussions about the System Security Services Daemon sssd-users@lists.fedorahosted.org Subject: [SSSD-users]Re: Kerberos ticket renewal with AD
On Tue, 1 Dec 2015, Thackeray, Neil L wrote:
I’m having this problem as well. This is only happening on Ubuntu machines for me, the RedHat and CentOS machines don’t seem to have this issue. I was starting to think this might be a problem with Kerberos libraries or something, otherwise I can’t understand why it wouldn’t work only on Ubuntu.
I monitor when one of my servers loses contact with the AD by running a cron script every 10 minutes: #!/bin/bash
HOST=`hostname` TST=`kinit -k 'SERVERNAME $@AD.MYDOMAIN.COM' 2>&1` if [ "$TST" != "" ]; then logger -p user.crit "SSSD AUTH ERROR: [$DATE] $TST on $HOST" DATE=`date` echo "[$DATE]" $TST>>/root/sssd-weirdness.txt fi
Have you got something in AD mandating machine password changes, or do you have something like msktutil running doing it for you?
jh
On Tue, 1 Dec 2015, Thackeray, Neil L wrote:
I don't control the AD, but I looked and couldn't find a policy mandating machine password changes outside of the standard time. I am not running msktutil, but I don't really see why I should have to. This is what sssd is supposed to be doing for me, and it's working just fine in CentOS and RedHat out of the box.
You *shouldn't* need to, but if something was periodically updating the machine password on this machine of yours, as is the norm with windows, and as can be acheived with certain tools, and wasn't updating the keytab, you'd presumably see this.
This isn't an SSSD issue.
Your issue is that your keytab isn't valid after a week.
jh
On Tue, 1 Dec 2015, John Hodrien wrote:
On Tue, 1 Dec 2015, Thackeray, Neil L wrote:
I don't control the AD, but I looked and couldn't find a policy mandating machine password changes outside of the standard time. I am not running msktutil, but I don't really see why I should have to. This is what sssd is supposed to be doing for me, and it's working just fine in CentOS and RedHat out of the box.
You *shouldn't* need to, but if something was periodically updating the machine password on this machine of yours, as is the norm with windows, and as can be acheived with certain tools, and wasn't updating the keytab, you'd presumably see this.
This isn't an SSSD issue.
Your issue is that your keytab isn't valid after a week.
When it breaks, do a klist -k to see the current state of your keytab.
Then do a:
kvno HOSTNAME$
Those numbers should match. If kvno returns a higher number, then something has changed the password and not updated the keytab.
jh
On Tue, Dec 01, 2015 at 03:30:32PM +0100, Andy Airey wrote:
What I am experiencing is that I can use the machine for 7 days until the TGT in SSSD's ccache expires.
So you mean the ticket in /var/lib/sss/db/ccache_example.com and after 7days you have to re-join the domain? In this case I guess there is some strict AD policy applied which requires that the keytab has to be renewed at least every 7days otherwise it becomes invalid and cannot be re-used anymore.
As recommended in other emails as well I would try to run 'msktutil auto-update' in a daily cron jobs. I would expect that you have to use the --auto-update-interval option as well because by default msktutil updates the keytab only ever 30d (which is the default for AD clients) and cannot read the current value expected by AD because this is buried in a GPO.
Please note that this is completely unrelated to the ticket renewable feature.
HTH
bye, Sumit
With "use" I mean:
- LDAP lookups with SASL-GSSAPI binds for automount maps and sudoRoles
- login to the machine both with GSSAPI and password
When the ticket expires, the connection to AD is gone completely. My understanding was that, with the krb5_renew* settings, this would be resolved.
It seems like I'm getting this wrong, but is there a way to get a new TGT (with new renew until) through SSSD? Cron 'kinit -k' every week? Doesn't sound like the right way to do it.
On 1 December 2015 at 15:13, Sumit Bose sbose@redhat.com wrote:
On Tue, Dec 01, 2015 at 02:59:02PM +0100, Andy Airey wrote:
I don't mind the limit as such. I'm just looking to see how I can keep the machine joined to the domain
and
be able to login after said limit/renewable_lifetime.
What do you mean by "keep the machine joined to the domain". I thought you were talking of TGTs for user principals.
If you want to get a fresh TGT (including a fresh renew until) for the host itself you can just use the keytab by calling
kinit -k
Can you describe your use-case in more details?
Thank you.
bye, Sumit
On 1 December 2015 at 14:11, Ondrej Valousek <
Ondrej.Valousek@s3group.com>
wrote:
Yes - I would only add one thing - if you are unhappy with the 7 days limit, you can change default KDC settings in the domain policy for
your AD
(which defaults to 7 days). I have changed it to 14 days for example. O.
-----Original Message----- From: Sumit Bose [mailto:sbose@redhat.com] Sent: Tuesday, December 01, 2015 2:08 PM To: End-user discussions about the System Security Services Daemon < sssd-users@lists.fedorahosted.org> Subject: [SSSD-users]Re: Kerberos ticket renewal with AD
On Tue, Dec 01, 2015 at 01:42:26PM +0100, Andy Airey wrote:
I agree on the lifetime of 7 days, that's fine.
What I want to achieve is that I do not have to manually kinit the machine again. So that our users kan keep logging on, even after 7 days. I thought SSSD would do this for me. I cannot log in to each server everytime to make sure a new krbtgt is there ...
As per the manpage of kinit:
*-R*
requests renewal of the ticket-granting ticket. Note that an
expired
ticket cannot be renewed, even if the ticket is still within its renewable life.
If SSSD does a kinit -R, it should get a new krbtgt with a new expiration date that's 7 days ahead, right?
no, there are 2 different time. One is the plain lifetime of the ticket the other is the renewable lifetime which relate to option -l and -r of kinit respectively.
$ kinit -l 100s -r 200s admin Password for admin@IPA.DEVEL:
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:03:41 01.12.2015 14:05:19 krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
$ kinit -R
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:04:05 01.12.2015 14:05:43 krbtgt/IPA.DEVEL@IPA.DEVEL renew until 01.12.2015 14:06:59
As you can see the Expires time changes after 'kinit -R' but not the 'renew until' time.
HTH
bye, Sumit
On 1 December 2015 at 13:26, John Hodrien J.H.Hodrien@leeds.ac.uk
wrote:
On Tue, 1 Dec 2015, Andy Airey wrote:
Hi, > > If I read the manpage http://linux.die.net/man/5/sssd-krb5 > correctly, the setting krb5_renew_interval suggests that the
krbtgt
> gets renewed. > > I thought this meant that the ticket gets renewed (a new krbtgt is > generated) before the 7 days come to an end. > Now, 7 days after kinit, we cannot log on tp the machine anymore > with our > krb5 credentials. >
It'll get renewed regularly, as the valid lifetime of your ticket will be more like 10/12 hours. Just do a kinit, then klist, and
see
what it tells you. You can ask for a longer life ticket, but AFAIK AD defaults to a
max
of 7 days. A long life ticket isn't particularly nice from a security point of view either.
If there is another way, please enlighten me :). >
SSSD can renew until it can't. In your original post you showed:
"renew until 12/07/15 13:16:40"
You can renew until that point, but you're not allowed to get a credential valid after that point, so without a password you can feed to the KDC, or additional privs for the machine, you're done
aren't you?
It's doing nothing more than a kinit -R as I understand it, and
it's
bound by the same limitations.
jh _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedoraho
sted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahost
ed.org
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof.
If
you have received this e-mail in error, please notify the sender by
return
e-mail and delete all copies of this e-mail from your computer
system(s).
Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered
in
Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users@lists.fedorahosted.org
-
Andy Airey -
John Hodrien -
mathias dufresne -
Ondrej Valousek -
Sumit Bose -
Thackeray, Neil L