Re: Kerberos ticket renewal with AD
by Sumit Bose
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#w2...
>
>
> 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
8 years, 4 months
Announcing SSSD 1.13.3
by Jakub Hrozek
== 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
8 years, 4 months
sssd & openldap password expiration
by Mario Rossi
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...>?
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
8 years, 4 months
How to filter out nss services request to backend just like filter_users
by aaron wang
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
8 years, 4 months
krb5 cache renewal question
by Ondrej Valousek
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.
8 years, 4 months
A RHEL-6.8 preview repo
by Jakub Hrozek
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
8 years, 4 months
newgrp problem
by Ondrej Valousek
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.
8 years, 4 months
pam_sss refused the connection from su
by aaron wang
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
8 years, 4 months
Kerberos tgt renewal for logged out users
by olle Hansson
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
8 years, 4 months
