Cannot get kernel keyring ccache to work with Ubuntu Trusty (even wiith updated SSSD and kernel)
by Joschi Brauchle
Hello everyone,
I cannot get kernel keyring caches to work with Ubuntu Trusty (when
copying a fully working configuration from openSUSE 13.2).
Scenario:
===========================
I am trying to use persistent kernel keyring ccaches with Ubuntu Trusty,
which comes with
- SSSD 1.11.x
- MIT kerberos libs 1.12.x
- Kernel 3.13.x
All these components should support kernel keyring ccaches. Is this correct?
In order to debug the problem, I updated SSSD to 1.12.5 and the kernel
to 3.19. But still the problem persists, thus I'm asking for help here...
Setup:
===========================
I enable persistent keyring ccaches like so in /etc/krb5.conf:
--------------
[libdefaults]
...
default_ccache_name = KEYRING:persistent:%{uid}
--------------
Symptoms:
============================
First of all, none of the problems described next occur when using FILE
ccaches (default setting).
I can log into the machine, but no ccache is created for my user, see
--------------
Could not chdir to home directory /home/<user>: Permission denied
/usr/bin/xauth: timeout in locking authority file /home/<user>/.Xauthority
-bash: /home/<user>/.bash_profile: Permission denied
$ echo $KRB5CCNAME
KEYRING:persistent:3036404
$ klist
klist: No credentials cache found while retrieving principal name
--------------
Doing a manual kinit now does create the ccache successfully:
--------------
$ klist
klist: No credentials cache found while retrieving principal name
$ kinit
Password for username@REALM:
$ klist
Ticket cache: KEYRING:persistent:3036404:3036404
Default principal: username@REALM
Valid starting Expires Service principal
11/07/2015 13:58:23 11/07/2015 23:58:23 krbtgt/REALM@REALM
renew until 11/14/2015 13:58:21
--------------
But note the strange ccache name with twice the UID. This looks not
right. I am expecting something like
"KEYRING:persistent:3036404:krb_ccache_RANDOM" ...
Logs of SSSD 1.12.5 and using Kernel 3.19. on Trusty:
============================
- krb5_child.log: http://paste.opensuse.org/view/raw/eb52751d
- strace of backend process: http://paste.opensuse.org/view/raw/85f09d65
I obfuscated parts of the logs, removing my username, realm, hostname
and domainname.
The strace shows some interesting keyctl errors:
ENOKEY (Required key not available)
Thanks for any suggestions on how to fix the problem!
- J Brauchle
8 years, 5 months
Re: [SSSD-users] sssd fails - too many open files
by Andy Airey
Hi,
I have the same issue.
It seems to hit a limit of 1024.
This is on CentOS 6.7.
Output below:
[root@localhost ~] ls -l /proc/`pgrep sssd_be`/fd/ | wc -l
1024
[root@localhost ~] cat /etc/redhat-release
CentOS release 6.7 (Final)
There is a way of increasing this limit, but it seems strange that we hit
this limit ...
Kind Regards,
Andy
8 years, 5 months
Re: [SSSD-users] sssd fails - too many open files
by Andy Airey
Hi,
I have the same issue.
It seems to hit a limit of 1024.
This is on CentOS 6.7.
Output below:
[root@localhost ~] ls -l /proc/`pgrep sssd_be`/fd/ | wc -l
1024
[root@localhost ~] cat /etc/redhat-release
CentOS release 6.7 (Final)
There is a way of increasing this limit, but it seems strange that we hit
this limit ...
Kind Regards,
Andy
8 years, 5 months
SSSD & Kerberos renewal
by Ondrej Valousek
Hi list,
I have a question regarding Kerberos cache refresh. My observation is, that normally sssd refreshes my cache just fine, but if I create Kerberos cache manually using kinit like this:
$ ssh root@remote_machine
Remote_machine # su - Ondrej
Remote_machine $ kinit Ondrej
... my cache is never renewed. Is this a normal behaviour? Is there any way how to "register" this cache with SSSD so it can take a care of it as well?
Note that normally the SSSD ticket cache is created in format of:
FILE:/tmp/krb5cc_<uid>_random
Whereas kinit's is:
FILE:/tmp/krb5cc_<uid>
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, 5 months
Re: [SSSD-users] netlink messages on Infiniband causing sssd to exit
by Ryan Novosielski
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Apologies for not starting with any of this info -- I was copying from
an internal e-mail and didn't think to add it all in to a mailing list
message. I am running CentOS 6.6 and SSSD 1.11.6.
On 11/04/2015 04:10 AM, Jakub Hrozek wrote:
> On Tue, Nov 03, 2015 at 04:15:57PM -0500, Novosielski, Ryan wrote:
>> Over time, I’ve been having seemingly random sssd quits that
>> I’ve not been able to figure out. Today, I finally traced it to
>> fluctuations on my Infiniband fabric:
>>
>> sssd.log
>>
>> (Tue Nov 3 13:17:59 2015) [sssd] [message_type] (0x0200):
>> netlink Message type: 16 (Tue Nov 3 13:17:59 2015) [sssd]
>> [link_msg_handler] (0x1000): netlink link message: iface idx 4
>> (ib0) flags 0x1003 (broadcast,multicast,up) (Tue Nov 3 13:17:59
>> 2015) [sssd] [message_type] (0x0200): netlink Message type: 16
>> (Tue Nov 3 13:17:59 2015) [sssd] [link_msg_handler] (0x1000):
>> netlink link message: iface idx 4 (ib0) flags 0x11043
>> (broadcast,multicast,up,running,lower)
>
> These messages should just tell sssd to reset its online/offline
> status. It's possible we have a bug there, but this code should be
> pretty stable, there were no changes there recently. Maybe the
> services don't handle the resetOffline signal well, but that's
> just my speculation.
A colleague was thinking maybe a status change that happens inside of
one second like this?
> There's no way to disable the netlink integration except for build
> changes.
>
>> This exactly corresponds to the time in /var/log/messages for
>> the unexplained shutdown:
>>
>> 2015-11-03T13:17:59-05:00 node75 sssd[pam]: Shutting down
>> 2015-11-03T13:17:59-05:00 node75 sssd[be[default]]: Shutting down
>> 2015-11-03T13:17:59-05:00 node75 sssd[nss]: Shutting down
>>
>> Here is sssd_default.log for good measure:
>>
>> (Tue Nov 3 13:17:59 2015) [sssd[be[default]]]
>> [sbus_remove_watch] (0x2000): 0x1414770/0x14133d0 (Tue Nov 3
>> 13:17:59 2015) [sssd[be[default]]] [sbus_remove_watch] (0x2000):
>> 0x1414770/0x13fef90 (Tue Nov 3 13:17:59 2015)
>> [sssd[be[default]]] [be_ptask_destructor] (0x0400): Terminating
>> periodic task [Cleanup of default] (Tue Nov 3 13:17:59 2015)
>> [sssd[be[default]]] [sdap_handle_release] (0x2000): Trace:
>> sh[0x14bd850], connected[1], ops[(nil)], ldap[0x1424260],
>> destructor_lock[0], release_memory[0] (Tue Nov 3 13:17:59 2015)
>> [sssd[be[default]]] [remove_connection_callback] (0x4000):
>> Successfully removed connection callback. (Tue Nov 3 13:17:59
>> 2015) [sssd[be[default]]] [sbus_remove_watch] (0x2000):
>> 0x1415970/0x1416430 (Tue Nov 3 13:17:59 2015)
>> [sssd[be[default]]] [remove_socket_symlink] (0x4000): The symlink
>> points to [/var/lib/sss/pipes/private/sbus-dp_default.18702] (Tue
>> Nov 3 13:17:59 2015) [sssd[be[default]]]
>> [remove_socket_symlink] (0x4000): The path including our pid is
>> [/var/lib/sss/pipes/private/sbus-dp_default.18702] (Tue Nov 3
>> 13:17:59 2015) [sssd[be[default]]] [remove_socket_symlink]
>> (0x4000): Removed the symlink (Tue Nov 3 13:17:59 2015)
>> [sssd[be[default]]] [be_client_destructor] (0x0400): Removed PAM
>> client (Tue Nov 3 13:17:59 2015) [sssd[be[default]]]
>> [be_client_destructor] (0x0400): Removed NSS client
>
> Is there anything else in the logs? Can you look for messages just
> before the "server_setup" line? (The server_setup function is the
> first one we print after startup)
They were above. Here's an excerpt from the right spot in sssd.log.
Everything relevant, IMO, happened in that one second.
(Tue Nov 3 13:17:59 2015) [sssd] [link_msg_handler] (0x1000): netlink
link message: iface idx 4 (ib0) flags 0x11043
(broadcast,multicast,up,running,lowerup)
(Tue Nov 3 15:38:56 2015) [sssd] [server_setup] (0x0400): CONFDB:
/var/lib/sss/db/config.ldb
The messages prior to that are just the normal stuff.
(Tue Nov 3 13:17:57 2015) [sssd] [service_send_ping] (0x0100):
Pinging nss
(Tue Nov 3 13:17:57 2015) [sssd] [sbus_add_timeout] (0x2000): 0x1b9fe20
(Tue Nov 3 13:17:57 2015) [sssd] [service_send_ping] (0x0100):
Pinging pam
(Tue Nov 3 13:17:57 2015) [sssd] [sbus_add_timeout] (0x2000): 0x1b9fe60
(Tue Nov 3 13:17:57 2015) [sssd] [sbus_remove_timeout] (0x2000):
0x1b9fe20
(Tue Nov 3 13:17:57 2015) [sssd] [sbus_dispatch] (0x4000): dbus conn:
0x1b9a5d0
(Tue Nov 3 13:17:57 2015) [sssd] [sbus_dispatch] (0x4000): Dispatching.
(Tue Nov 3 13:17:57 2015) [sssd] [ping_check] (0x0100): Service nss
replied to ping
(Tue Nov 3 13:17:57 2015) [sssd] [sbus_remove_timeout] (0x2000):
0x1b9fe60
(Tue Nov 3 13:17:57 2015) [sssd] [sbus_dispatch] (0x4000): dbus conn:
0x1b99cc0
(Tue Nov 3 13:17:57 2015) [sssd] [sbus_dispatch] (0x4000): Dispatching.
(Tue Nov 3 13:17:57 2015) [sssd] [ping_check] (0x0100): Service pam
replied to ping
> What about the sssd.log itself?
That's what is right above and what I'd posted before to show the
netlink messages. If you want the whole log, or a certain amount of
it, let me know where that would be helpful to send. I've had
debugging up quite high to try to track this one down, so it's rather
large.
>> I can duplicate this by manually taking down the Infiniband
>> link:
>>
>> [root@node24 ~]# service sssd status sssd (pid 9132) is
>> running... [root@node24 ~]# ifdown ib0 [root@node24 ~]# service
>> sssd status sssd dead but pid file exists
>
> What SSSD version are you running on what OS?
>
> If it's RHEL/Centos or some of its derivatives, can you enable
> abrt to see if there's any crash? Are there any sssd-related
> messages in syslog?
I will turn abrt on. The problem is extremely intermittent and these
are compute nodes having the problem, so it's going to take awhile to
get anything useful out of it.
The only messages in sssd were the ones printed first
(/var/log/messages), about it shutting down.
- --
____ *Note: UMDNJ is now Rutgers-Biomedical and Health Sciences*
|| \\UTGERS |---------------------*O*---------------------
||_// Biomedical | Ryan Novosielski - Senior Technologist
|| \\ and Health | novosirj(a)rutgers.edu - 973/972.0922 (2x0922)
|| \\ Sciences | OIRT/High Perf & Res Comp - MSB C630, Newark
`'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlY6Kc8ACgkQmb+gadEcsb6pLACZAbsRcZPEYiFyfODD46VZsths
XqEAn3WaGE5aAYLInDDiUE42IM47c7oj
=bNHL
-----END PGP SIGNATURE-----
8 years, 5 months
SSSD and accounts with UID = 0
by mathias dufresne
Hi all,
I'm trying to define in my AD administrative accounts for Linux boxes. To
do that I initially thought to create nominative account with some suffix
(ex: <username>_adm) and give them UID=0 to make them root accounts.
As SSSD comes with filtering option to avoid some users or groups can
connect on some given system using SSSD, I would have added these users to
some groups and finally grant access to one admins group to a first bunch
of systems, the secodn admins group to a second bunch of systems, etc...
Reading doc and man pages about SSSD sometimes it seems to say that is
possible to have users retrieved by SSSD when they have UID = 0, sometimes
it says it is not possible.
For example: man sssd.conf on Centos 7 (sssd 1.12.2
- 1.12.2-58.el7_1.17.x86_64) gives:
pam_trusted_users (string)
Specifies the comma-separated list of UID values or user names
that are allowed to access
the PAM responder. User names are resolved to UIDs at startup.
Default: all (All users are allowed to access the PAM responder)
* Please note that UID 0 is always allowed to access the PAM
responder even in case it is*
* not in the pam_trusted_users list.*
As man pages says users with "UID 0 is always allowed..." I would expected
this refers users retrieved by SSSD, so that SSSD accept to retrieve users
with UID=0.
Unfortunately even adding "min_id = 0" in my sssd.conf SSSD refuse to show
uid=0 users.
In SSSD logs I have ldapserach filter shown as follow:
(&(cn=<username>)(objectclass=user)(cn=*)(&(uidNumber=*)*(!(uidNumber=0))*))
And somewhere I read this is by design that now SSSD refuses to allow users
with UID=0.
As all that is not too clear for me, where are we now, are users with UID=0
allowed or not?
Cheers,
mathias
8 years, 5 months
sssd going offline because of DNS errors?
by Ondrej Valousek
Hi List,
I have a problem with sssd going randomly offline because of the following errors:
(Mon Nov 2 12:33:52 2015) [sssd[be[default]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD'
(Mon Nov 2 12:33:52 2015) [sssd[be[default]]] [resolve_srv_send] (0x0200): The status of SRV lookup is not resolved
(Mon Nov 2 12:33:52 2015) [sssd[be[default]]] [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'not working'
(Mon Nov 2 12:33:52 2015) [sssd[be[default]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (myserver.example.com), resolver returned (5)
<repeat the above 4 lines multiple times>
(Mon Nov 2 12:33:52 2015) [sssd[be[default]]] [be_resolve_server_process] (0x0040): Failed to find a server after 10 attempts
(Mon Nov 2 12:33:52 2015) [sssd[be[default]]] [be_ptask_enable] (0x0080): Task [Check if online (periodic)]: already enabled
(Mon Nov 2 12:33:52 2015) [sssd[be[default]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks.
It happens only from time to time - I am pretty sure my DNS is working correctly so not sure what could be the problem.
What does it mean "resolver returned (5)"?
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, 5 months
Local Administrators (group) and delegation in AD
by Davor Vusir
Hi all!
We have got many delegations in our AD. To add a certain administrator
group to the local Administrators group you can use GPO for
Windowsservers. As Samba does not understand GPO I have initially used
the "username map" feature to add a domain account to become root. After
the appropriate group is added via Computer Management MMC by the
delegated administrator, the line "username map" is commented and Samba
is restarted. After this procedure the delegated administrators have got
proper access to the server. Not using this feature of course renders
access denied error when attempting to add an AD-group to the local
Administrators group.
If Winbind is disabled you get the well known SID in members list in the
properties dialog for the local Administrators group instead of the
human readable names (AD\Domain Admins...).
We are using SSSD to retrieve user- and groupinfo from AD, therefore is
the AD-backend commented in smb.conf.
https://fedorahosted.org/sssd/wiki/HOWTO_Configure_1_0_2 mentions that
the local provider is using LDB-files for storing information. Is it
possible to use the files used by Samba/Winbind to retrieve the users
and groups in the local "SAM", eg the local Administrators and Users group?
Regards
Davor vusir
Relevant part of smb.conf:
# username map = /etc/samba/usermap
idmap config *:backend = tdb
idmap config *:range = 2200000001-2200100000
# idmap config AD:backend = ad
# idmap config AD:schema_mode = rfc2307
# idmap config AD:range = 1000-2200000000
# winbind nss info = rfc2307
Relevant part of nsswitch.conf:
passwd: files sss winbind
shadow: files
group: files sss winbind
8 years, 5 months