sssd-users December 2015

sssd-users@lists.fedorahosted.org

21 participants
25 discussions

Re: Kerberos ticket renewal with AD
by Sumit Bose 17 Dec '15

17 Dec '15

On Tue, Dec 01, 2015 at 07:02:53PM +0100, Andy Airey wrote: > Sumit, > > 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. > > > Indeed, that is the case. > However, the default "Maximum lifetime for user ticket renewal" is 7d [1]. > And there is no such policy that I am aware of (I manage AD too, it hurts > sometimes). > > 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. > > > I will try out 'msktutil' and be sure to report back. > Although I don't know of anything changing machine passwords (except AD > itself?). It might just expire it. > > Please note that this is completely unrelated to the ticket renewable > > feature. > > > Sorry for the misunderstanding. It wasn't crystal clear to me. > Can you confirm the following; SSSD does ask for a reneweable ticket *and* > can renew a current TGT or service principal ticket. > However, it cannot request a *new* TGT. > Correct? yes, but this workflow is for users which try to log in to the system. During authentication SSSD (if configured for Kerberos authentication) tired to get a TGT for the user and if configured tries to renew the ticket as long as a process of the user is still running on the system and the TGT is still renewable. For a user SSSD cannot request a new TGT on its own because this requires the user password which in general is not kept by SSSD for security reasons. Btw, service tickets cannot be renewed but a fresh one will be requested as long as the TGT is valid. But, this is different for the machine password. The machine password is generated randomly during the join and hashes of the password are stored in the host keytab, by default /etc/krb5.keytab. The content of the keytab file is as good as a password and should be handled with the same care as a plain text password. With the keytab you can get a fresh TGT, just call 'kinit -k'. SSSD uses the keytab to get a TGT to e.g. be able to connect to the AD LDAP service which by default only allows authenticated access. If the TGT becomes invalid SSSD will just use the keytab again to get a fresh TGT, no renewal is involved here. If now the machine password expires on the server side SSSD depends on external tools like msktutil to renew it. HTH bye, Sumit > > > Thanks for the replies, this has been really helpful so far. > > Kind Regards, > > > Andy > > [1] > https://technet.microsoft.com/nl-be/library/cc738673%28v=ws.10%29.aspx#w2k3… > > > On 1 December 2015 at 18:15, Sumit Bose <sbose(a)redhat.com> wrote: > > > 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(a)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(a)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(a)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(a)IPA.DEVEL: > > > > > > > > > > > > $ klist > > > > > > Ticket cache: KEYRING:persistent:1000:1000 Default principal: > > > > > > admin(a)IPA.DEVEL > > > > > > > > > > > > Valid starting Expires Service principal > > > > > > 01.12.2015 14:03:41 01.12.2015 14:05:19 > > krbtgt/IPA.DEVEL(a)IPA.DEVEL > > > > > > renew until 01.12.2015 14:06:59 > > > > > > > > > > > > $ kinit -R > > > > > > > > > > > > $ klist > > > > > > Ticket cache: KEYRING:persistent:1000:1000 Default principal: > > > > > > admin(a)IPA.DEVEL > > > > > > > > > > > > Valid starting Expires Service principal > > > > > > 01.12.2015 14:04:05 01.12.2015 14:05:43 > > krbtgt/IPA.DEVEL(a)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(a)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(a)lists.fedorahosted.org > > > > > > > > > > > > > > > > > > > > https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedoraho > > > > > > > > sted.org > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > sssd-users mailing list > > > > > > > sssd-users(a)lists.fedorahosted.org > > > > > > > > > > > https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahost > > > > > > > ed.org > > > > > > _______________________________________________ > > > > > > sssd-users mailing list > > > > > > sssd-users(a)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(a)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(a)lists.fedorahosted.org > > > > > > > > > > > > > > > > > > https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org > > > > > > > > > > > > > > > _______________________________________________ > > > > > sssd-users mailing list > > > > > sssd-users(a)lists.fedorahosted.org > > > > > > > > > > > https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org > > > > _______________________________________________ > > > > sssd-users mailing list > > > > sssd-users(a)lists.fedorahosted.org > > > > > > > > > > https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org > > > > > > > > > _______________________________________________ > > > sssd-users mailing list > > > sssd-users(a)lists.fedorahosted.org > > > > > https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org > > _______________________________________________ > > sssd-users mailing list > > sssd-users(a)lists.fedorahosted.org > > > > https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org > > > _______________________________________________ > sssd-users mailing list > sssd-users(a)lists.fedorahosted.org > https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

2 1

Announcing SSSD 1.13.3
by Jakub Hrozek 15 Dec '15

15 Dec '15

== SSSD 1.13.3 === The SSSD team is proud to announce the release of version 1.13.3 of the System Security Services Daemon. As always, the source is available from https://fedorahosted.org/sssd RPM packages will be made available for Fedora shortly. == Feedback == Please provide comments, bugs and other feedback via the sssd-devel or sssd-users mailing lists: https://lists.fedorahosted.org/mailman/listinfo/sssd-devel https://lists.fedorahosted.org/mailman/listinfo/sssd-users == Highlights == * A bug that prevented user lookups and logins after migration from winsync to IPA-AD trusts was fixed * The OCSP certificate validation checks are enabled for smartcard logins if SSSD was compiled with the NSS crypto library. * A bug that prevented the ignore_group_members option from working correctly in AD provider setups that use a dedicated primary group (as opposed to a user-private group) was fixed * Offline detection and offline login timeouts were improved for AD users logging in from a domain trusted by an IPA server * The AD provider supports setting up autofs_provider=ad * Several usability improvements to our debug messages == Packaging Changes == * The p11_child helper binary is able to run completely unprivileged and no longer requires the setgid bit to be set == Documentation Changes == * A new option certificate_verification was added. This option allows the administrator to disable OCSP checks in case the OCSP server is not reachable == Tickets Fixed == https://fedorahosted.org/sssd/ticket/1632 [RFE] Unable to use AD provider for automount lookups https://fedorahosted.org/sssd/ticket/1943 convert sudo timer to be_ptask https://fedorahosted.org/sssd/ticket/2672 sudo: reload hostinfo when going online https://fedorahosted.org/sssd/ticket/2732 Add Integration tests for local views feature https://fedorahosted.org/sssd/ticket/2747 get_object_from_cache() does not handle services https://fedorahosted.org/sssd/ticket/2755 Review p11_child hardening https://fedorahosted.org/sssd/ticket/2787 We should mention SSS_NSS_USE_MEMCACHE in man sssd.conf(5) as well https://fedorahosted.org/sssd/ticket/#2796 fix man page for sssd-ldap https://fedorahosted.org/sssd/ticket/2801 Check next certificate on smart card if first is not valid https://fedorahosted.org/sssd/ticket/2812 Smartcard login when certificate on the card is revoked and ocsp check enabled is not supported https://fedorahosted.org/sssd/ticket/2830 Try to suppress "Could not parse domain SID from [(null)]" for IPA users https://fedorahosted.org/sssd/ticket/2846 Inform about SSSD PAC timeout better https://fedorahosted.org/sssd/ticket/2868 AD provider and ignore_group_members=True might cause flaky group memberships https://fedorahosted.org/sssd/ticket/2874 sssd: [sysdb_add_user] (0x0400): Error: 17 (File exists) == Detailed Changelog == Dan Lavu (1): * Clarify that subdomains always use service discovery Jakub Hrozek (7): * Upgrading the version for the 1.13.3 release * DP: Do not confuse static analysers with dead code * BUILD: Only install polkit rules if the directory is available * IPA: Use search timeout, not enum timeout for searching overrides * AD: Add autofs provider * MAN: Clarify when should TGs be disabled for group nesting restriction * Update translations for the 1.13.3 release Lukas Slebodnik (2): * sbus_codegen_tests: Use portable definition of large constants * DEBUG: Add missing new lines Michal Židek (1): * MAN: sssd.conf should mention SSS_NSS_USE_MEMCACHE Pavel Březina (22): * SYSDB: Add missing include to sysdb_services.h * LDAP: Mark globals in ldap_opts.h as extern * AD: Mark globals in ad_opts.h as extern * IPA: Mark globals in ipa_opts.h as extern * KRB5: Mark globals in krb5_opts.h as extern * SUDO: convert periodical refreshes to be_ptask * SUDO: move refreshes from sdap_sudo.c to sdap_sudo_refresh.c * SUDO: move offline check to handler * SUDO: simplify error handling * SUDO: fix sdap_id_op logic * SUDO: fix tevent style * SUDO: fix sdap_sudo_smart_refresh_recv() * SUDO: sdap_sudo_load_sudoers improve iterator * SUDO: set USN inside sdap_sudo_refresh request * SUDO: built host filter inside sdap_sudo_refresh request * SUDO: do not imitate full refresh if usn is unknown in smart refresh * SUDO: fix potential memory leak in sdap_sudo_init * SUDO: obtain host information when going online * SUDO: remove finalizer * SUDO: make sdap_sudo_handler static * SUDO: use size_t instead of int in for cycles * SUDO: get srv_opts after we are connected Pavel Reichl (1): * sysdb-tests: Fix warning - incompatible pointer type Petr Cech (2): * IPA_PROVIDER: Explicit no handle of services * KRB5_CHILD: Debug logs for PAC timeout Sumit Bose (7): * IPA: fix override with the same name * p11: allow p11_child to run completely unprivileged * p11: check if cert is valid before selecting it * p11: enable ocsp checks * ldap: skip sdap_save_grpmem() if ignore_group_members is set * initgr: only search for primary group if it is not already cached * LDAP: check early for missing SID in mapping check

1 0

sssd & openldap password expiration
by Mario Rossi 07 Dec '15

07 Dec '15

Hi, We have the need to add password (not account) expiration in ldap and I see that sssd supports pwd policies. What's the recommended way of achieving password expiration keeping in mind the following: * currently there are no shadow attributes defined ( all users have shadowAccount objectclass but no attrs like shadowExpire / shadowMin / shadowMax ) * upon the user logging in , if password is going to expire in a few days, display a message to the user ( pam_account_expired_message , pam_pwd_expiration_warning ? ) * is sssd-1.12.4-47 rpm recommended or better sssd-1.12.5-3 <https://copr-be.cloud.fedoraproject.org/results/lslebodn/sssd-1-12/epel-6-x…>? I found out the hard way that I need to define shadowExpire to -1 otherwise users get rejected with 'account has expired' message in sssd debug mode but perhaps my settings are wrong. What shadow attributes does sssd look for in the openldap tree ? [pam] ... pam_pwd_expiration_warning = 21 pam_account_expired_message = Account/password expired, please use selfservice portal to change your password and extend account. [domain/LDAP] ... # Account expiration ldap_account_expire_policy = shadow # Password expiration #ldap_pwd_policy = none ldap_pwd_policy = shadow ldap_pwdlockout_dn = cn=default,ou=policies,o=Hostopia,dc=hostopia,dc=com ldap_access_order = filter, expire pwd_expiration_warning = 21 ... Seems that I should be looking at src/providers/ldap/ldap_opts.h & src/providers/ldap/sdap.h . Thank you, Mario Rossi

2 2

How to filter out nss services request to backend just like filter_users
by aaron wang 04 Dec '15

04 Dec '15

Hi All, The issue is: I'm using "authconfig --enablesssd --enablesssdauth --enablelocauthorze --update" to configure the /etc/nsswitch The authconfig put in the entry like this : "services: files sss" So what happens is, LDAP server is getting a lot of requests like this: *[***sanitzied fields***] filter="(&(cn=ntp)(ipServiceProtocol=sctp)(objectClass=ipService))" attrs="objectClass cn ipServicePort ipServiceProtocol modifyTimestamp"* I don't see any options that authconfig has to avoid including sss in nss services for now. So is there anything I can use on the SSSD side to filter out nss services requests ? Thanks, Aaron

3 7

krb5 cache renewal question
by Ondrej Valousek 04 Dec '15

04 Dec '15

Hi List, Question: If I do: Service sssd stop Rm -rf/var/lib/sssd/db/* Service sssd start - Will SSSD forget about users logged to the system so far so it will no longer refresh their credential cache? Thanks, Ondrej ----- 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(a)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.

2 2

A RHEL-6.8 preview repo
by Jakub Hrozek 03 Dec '15

03 Dec '15

Hi, At the moment, we plan for RHEL-6.8 to ship with SSSD 1.13. To get some early testing, here is an automatically-updated COPR repo with the preview packages: https://copr.fedoraproject.org/coprs/jhrozek/SSSD-6.8-preview/ We will be glad for test results and/or bug reports, but please read the repo description carefully before putting these packages on your systems, especially the "NOT SUPPORTED by Red Hat" part. For convenience, I copied the description below: Q: What is the OS and release these packages are supposed to run with? A: RHEL-6.7 or CentOS-6.7. Q: How often are these packages updated? A: When a new build happens in RHEL, except when the fix should not be released in public yet (think CVE) Q: Are all RHEL-6.8 features or bug fixes included? A: Looking at 1.13.x Trac milestones might give a rough idea, but it's best to contact Red Hat Support and ask about a particular feature/bug status. Q: Can I update from these packages to RHEL-6.8 proper? A: That is not supported and we won't do any special work towards making the upgrade path smooth. These packages are meant to be tried in a test VM or similar environment. Q: I found a bug in these packages! A: Thank you for trying them out! Please file a bug report in SSSD Trac or ask for help on the sssd-users list

2 2

newgrp problem
by Ondrej Valousek 03 Dec '15

03 Dec '15

Hi List, I have a strange problem with newgrp. Machine is running SSSD, user U is member of groups G1,G2,G3. 'id -a U' shows correctly membership G1,G2,G3 Now command 'newgrp G1' completes successfully for him, but command 'newgrp G2' prompts for password. Any other user, member of the same groups do not have a problem with 'newgrp G2'. Just this particular user. Strace did not unveil anything useful. Does anyone hit the same problem? Thanks, Ondrej ----- 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(a)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.

3 7

pam_sss refused the connection from su
by aaron wang 02 Dec '15

02 Dec '15

Hi All, I'm seeing this kind of error logs in my linux environment: *pam_sss(su:session): Request to sssd failed. Connection refused* This error logs shows up constantly, I guess there are some cron jobs are trying to run sudo commands, but the connection request from pam_sss to sssd is refused. session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so Above is the session section from system-auth file, I used "authconfig --enablesssd --enablesssdauth --enablelocauthorize --update" to configure the system files. 1. "service sssd status" is returning running, and I can ssh login local linux users and also ldap users. 2. I commented our "session optional pam_sss.so" , the error logs still coming out constantly. Any idea about debugging this problem ? Or is there a known issue about this ? Thanks, Aaron

1 1

Kerberos tgt renewal for logged out users
by olle Hansson 02 Dec '15

02 Dec '15

Hi all, I've noticed that tickets do not get renewed if the user logs out. Is this intentional even if the ticket cache is stored in the user home? If so is there any way to make sssd renew tickets even for users who no longer have a session open on the server so they can run cron jobs etc? Regards Olle

4 5

[PATCH] make globals in *_opts.h extern
by Pavel Březina 02 Dec '15

02 Dec '15

This solves situation where you want to use those globals on other place than in *_common.c. I also created https://fedorahosted.org/sssd/ticket/2890 so we can avoid order-dependency on header files such as sysdb_services.h which I had to fix for AD patch.

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users December 2015