full_name_format and supplemental groups
by Orion Poplawski
Running IPA with an AD trust. Users are in AD. Trying to use
full_name_format = %1$s to strip the domain from user names. This appears to
break supplemental groups in strange ways.
On the IPA server:
Without full_name_format:
# id orion(a)ad.nwra.com
uid=470202603(orion(a)ad.nwra.com) gid=470202603(orion(a)ad.nwra.com)
groups=470202603(orion(a)ad.nwra.com),470200513(domain
users(a)ad.nwra.com),470204703(pirep rd users(a)ad.nwra.com),470204714(wireless
access@ad.nwra.com),470204715(nwra-users@ad.nwra.com),470204701(boulder(a)ad.nwra.com),470207608(heimdall
users(a)ad.nwra.com),470200512(domain admins(a)ad.nwra.com),470207124(andreas
admins(a)ad.nwra.com)
With:
# id orion(a)ad.nwra.com
uid=470202603(orion) gid=470202603(orion) groups=470202603(orion)
If I add:
default_domain_suffix = ad.nwra.com
# id orion
uid=470202603(orion) gid=470202603(orion)
groups=470202603(orion),470200512(domain admins),470207608(heimdall
users),470204714(wireless
access),470204715(nwra-users),470204701(boulder),470204703(pirep rd
users),470207124(andreas admins),470200513(domain users)
Which I guess makes some sense as you'd need to add the domain suffix back on
to find the groups.
But this appears to completely break IPA clients (with full_name_format = %1$s
and default_domain_suffix = ad.nwra.com):
# id orion(a)ad.nwra.com
id: orion(a)ad.nwra.com: no such user
# id orion
id: orion: no such user
>From looking at the server logs, it looks like only the IPA domain is searched
If I reset the server back to normal (drop full_name_format and
default_domain_suffix):
# id orion
uid=470202603(orion) gid=470202603(orion) groups=470202603(orion)
I don't get any supplemental groups. I see sssd errors like:
(Mon Mar 30 15:20:52 2015) [sssd[be[nwra.com]]] [sysdb_mod_group_member]
(0x0400): Error: 2 (No such file or directory)
(Mon Mar 30 15:20:52 2015) [sssd[be[nwra.com]]] [sysdb_update_members_ex]
(0x0020): Could not add member [orion] to group [name=domain
admins,cn=groups,cn=nwra.com,cn=sysdb]. Skipping.
Is t trying "cn=groups,cn=nwra.com,cn=sysdb" instead of
"cn=groups,cn=ad.nwra.com,cn=sysdb"
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
7 years, 1 month
please do not remove enumeration from AD provider
by James Ralston
On Wed, May 6, 2015 at 4:27 AM, Jakub Hrozek <jhrozek(a)redhat.com> wrote:
> You know, just this morning, I was thinking about enumeration. It
> doesn't work for IPA views at all for example. It doesn't work for
> trusted domains at all either (except for some limited support in AD
> trusted domains that is very untested)
>
> I wonder if we could just remove enumeration from IPA and AD back
> ends in some major release.
Please don't do this.
Enumeration is a very useful feature. It allows us to do things like
this:
$ getent passwd | grep -i lastname
The equivalent ldapsearch command is much more tedious:
$ ldapsearch -z 0 -E pr=2147483647/noprompt -o ldif-wrap=no -L -L -H
'ldap:///dc%3Dexample%2Cdc%3Dorg -Y GSSAPI -N -b "dc=example,dc=org"
"(&(objectClass=user)(cn=*lastname*))" dn cn sAMAccountName
More generically, enumeration is the way Unix/Linux has always worked.
Even getting users to change from:
grep -i lastname /etc/passwd
To this:
getent passwd | grep -i lastname
...has been a struggle.
We also have various services that (unfortuantely) pre-load the passwd
and group files at startup by enumerating them with getpwent_r() and
getgrent_r(), instead of using the get*nam_r() and get*id_r()
functions as-needed. These services break outright if enumeration is
disabled.
(Yes, these services are broken. Yes, they shouldn't do that. But our
ability to fix them is extremely limited at best, because we don't
control them.)
Finally, we have many systems that cannot be joined to Active
Directory (for policy reasons, not technical reasons). But we want to
use the same passwd/group entries on those systems as returned by sssd
on hosts that are joined to Active Directory. We do this by scraping
the output of "getent -s sss passwd" and "getent -s sss group" and
manually merging it into the local passwd and group files
(respectively) on these hosts.
> It's just a legacy feature, so those who need it can fall back to
> the LDAP provider..
But the LDAP provider doesn't support ID mapping; only the AD provider
does. And ID mapping is the main reason we use sssd.
I'm not asking you to make enumeration the default. It shouldn't be;
it should be something you only turn on if you need it, and you KNOW
you need it. But if you need it, you NEED it. Please don't take it
away.
7 years, 10 months
sssd+ad-provider + sudo slow
by Евгений
Hi All!
Work very well with sssd+ad provider, but sudo su - very slow working when running first time(running again <1sec),
user1@host$ sudo su - ( slow ~ 8-15 sec).
user1 domain user - member of many groups (+300) in Active Directory.
/etc/sssd/sssd.conf:
[domain/default]
cache_credentials = true
ignore_group_members = true
[domain/domain.local]
debug_level = 6
id_provider = ad
ad_server = msa-dc13. domain.local, msk-dc11. domain.local
ad_domain = domain.local
ad_hostname = msa-mailsys1.domain.local
override_homedir = /home/%u
override_shell = /bin/bash
ignore_group_members = true
# FILTER
access_provider = simple
simple_allow_groups = ROL-Linux-Admin
[sssd]
services = nss, pam, sudo
cache_credentials = true
config_file_version = 2
domains = domain.local
[nss]
debug_level= 6
[pam]
[sudo]
#debug_level = 9
In /var/log/sssd/sssd_nss.log more requesting to domain,when run sudo first time.
Whether it is possible to cache operations with sudo or or some other way to get around there is the problem?
--
Eugene
8 years, 3 months
Map an AD group to a local group
by Domenico Viggiani
Hi,
to preserve compatibility, I'd like to map the AD users' default group to a
local Linux group.
I don't want to add every AD user to the row in /etc/group and I don't want
to change default primary group of users in AD.
Is there a group mapping function in SSSD? Or am I completely wrong?
Thanks in advance
--
Domenico Viggiani
8 years, 4 months
SSSD is unable to go online on RHEL-6
by Ondrej Valousek
Hi List,
Facing another issue on RHEL-6. After server reboot, the sssd is unable to go online. Messages like:
(Fri Jul 3 06:13:36 2015) [sssd[be[default]]] [be_run_online_cb] (0x0080): Going online. Running callbacks.
(Fri Jul 3 06:13:42 2015) [sssd[be[default]]] [fo_resolve_service_timeout] (0x0080): Service resolving timeout reached
(Fri Jul 3 06:13:42 2015) [sssd[be[default]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error])
(Fri Jul 3 06:13:42 2015) [sssd[be[default]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks.
(Fri Jul 3 06:13:42 2015) [sssd[be[default]]] [ad_subdomains_get_conn_done] (0x0080): No AD server is available, cannot get the subdomain list while offline
(Fri Jul 3 06:13:42 2015) [sssd[be[default]]] [sdap_dyndns_get_addrs_done] (0x0080): No LDAP server is available, dynamic DNS update is skipped in offline mode.
(Fri Jul 3 06:13:42 2015) [sssd[be[default]]] [sdap_dyndns_update_addrs_done] (0x0040): Can't get addresses for DNS update
(Fri Jul 3 06:13:42 2015) [sssd[be[default]]] [ad_dyndns_sdap_update_done] (0x0040): Dynamic DNS update failed [1432158230]: Dynamic DNS update not possible while offline
(Fri Jul 3 06:13:42 2015) [sssd[be[default]]] [ad_dyndns_nsupdate_done] (0x0040): Updating DNS entry failed [1432158230]: Dynamic DNS update not possible while offline
(Fri Jul 3 06:13:42 2015) [sssd[be[default]]] [fo_resolve_service_timeout] (0x0080): Service resolving timeout reached
(Fri Jul 3 06:13:42 2015) [sssd[be[default]]] [be_ptask_enable] (0x0080): Task [Check if online (periodic)]: already enabled
(Fri Jul 3 06:13:42 2015) [sssd[be[default]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks.
(Fri Jul 3 06:14:52 2015) [sssd[be[default]]] [be_run_online_cb] (0x0080): Going online. Running callbacks.
(Fri Jul 3 06:14:58 2015) [sssd[be[default]]] [fo_resolve_service_timeout] (0x0080): Service resolving timeout reached
(Fri Jul 3 06:14:58 2015) [sssd[be[default]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks.
(Fri Jul 3 06:15:00 2015) [sssd[be[default]]] [sss_ldap_init_sys_connect_done] (0x0020): sdap_async_sys_connect request failed.
(Fri Jul 3 06:15:00 2015) [sssd[be[default]]] [sdap_sys_connect_done] (0x0020): sdap_async_connect_call request failed.
(Fri Jul 3 06:15:06 2015) [sssd[be[default]]] [sss_ldap_init_sys_connect_done] (0x0020): sdap_async_sys_connect request failed.
And strangely also:
(Fri Jul 3 06:19:37 2015) [sssd[be[default]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (SRV lookup meta-server), resolver returned (1432158227)
(Fri Jul 3 06:19:37 2015) [sssd[be[default]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (xxx.yyy.zzz), resolver returned (5)
(Fri Jul 3 06:19:37 2015) [sssd[be[default]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (xxx2.yyy.zzz), resolver returned (5)
Looks like DNS issue but I am pretty sure DNS worked just fine. After sssd restart everything goes just fine.
sssd-1.11.7-4.el6
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
Re: [SSSD-users] ssh passwordless with sssd-1.12.5 problem!!
by Longina Przybyszewska
Hi again,
After implementing the recommended change my setup seemed to work fine with passwordless SSH and kerberized NFS4.
Unexpectedly, after credentials expired (I got the message "key expired" !), I can't mount home directory at all, not only in ssh session, but also login locally to the client workstation.
After client reboot, access to users NFS homedir is lost as well.
Does the [plugin] change in krb5.conf could have impact on nfs service too?
[plugins]
localauth = {
module=sssd:/usr/lib/x86_64-linux- gnu/sssd/modules/sssd_krb5_localauth_plugin.so
enable_only = sssd
}
I noticed that SSH session uses in-MEMORY cache ; NFS server is setup with ccache in /tmp
If I compare ssh<->nfs sessions it seems that user's principal credentials never get through to the server.
(successful ssh session in the previous mail).
What is wrong?
------nfs session (rpc.svcgssd) on server-------
entering poll
leaving poll
handling null request
svcgssd_limit_krb5_enctypes: Calling gss_set_allowable_enctypes with 7 enctypes from the kernel
[6404] 1438257362.977400: Decrypted AP-REQ with server principal nfs/nfssrv.adm.c.sdu.dk(a)A.C.REALM: aes256-cts/0F5A
[6404] 1438257362.977427: AP-REQ ticket: LNX-LEIA$(a)A.C.REALM -> nfs/nfssrv.adm.c.sdu.dk(a)A.C.REALM, session key aes256-cts/DD8F
[6404] 1438257362.978032: Negotiated enctype based on authenticator: aes256-cts
[6404] 1438257362.978057: Authenticator contains subkey: aes256-cts/0652
[6404] 1438257362.978106: Creating AP-REP, time 1438257362.982778, subkey aes256-cts/41C3, seqnum 738956702
sname = LNX-LEIA$(a)A.C.REALM
DEBUG: serialize_krb5_ctx: lucid version!
prepare_krb5_rfc4121_buffer: protocol 1
prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32
doing downcall
mech: krb5, hndl len: 4, ctx len 52, timeout: 1438293240 (35878 from now), clnt: <null>, uid: -1, gid: -1, num aux grps: 0:
sending null reply
best
Longina
> -----Oprindelig meddelelse-----
> Fra: sssd-users-bounces(a)lists.fedorahosted.org [mailto:sssd-users-
> bounces(a)lists.fedorahosted.org] På vegne af Longina Przybyszewska
> Sendt: 14. juli 2015 17:08
> Til: 'End-user discussions about the System Security Services Daemon'
> Emne: Re: [SSSD-users] ssh passwordless with sssd-1.12.5
>
> Hi again,
> Thanks - it seems to work!
> I am not sure if k5login directory and .k5login play any role in success - I need
> to check it out.
>
> First, I put k5login entries into krb5.conf on both, client and server, and tried
> ssh - It didn't work, I was asked for password.
>
> [krb5.conf] on both.
> ...
> k5login_directory = /usr/share/ssh/%u
> k5login_authoritative = true
> ignore_acceptor_hostname = true
> ...
> .....
>
>
> [Kerberos part of output from " KRB5_TRACE=/tmp/1.txt /usr/sbin/sshd -D -
> d -d -d "]
>
> less 1.txt
>
>
> [2863] 1436879405.741004: Decrypted AP-REQ with server principal
> LX101$(a)A.C.REALM: aes256-cts/2CCB [2863] 1436879405.741095: AP-REQ
> ticket: longina(a)N.C.REALM-> LX101$(a)A.C.REALM, session key aes256-
> cts/2E16 [2863] 1436879405.799281: Negotiated enctype based on
> authenticator: aes256-cts [2863] 1436879405.799314: Authenticator contains
> subkey: aes256-cts/1399 [2863] 1436879405.799475: Resolving unique ccache
> of type MEMORY [2863] 1436879405.799493: Initializing MEMORY:pvs4jFN
> with default princ longina(a)N.C.REALM [2863] 1436879405.799504: Removing
> longina(a)N.C.REALM-> krbtgt/N.C.REALM(a)N.C.REALM from
> MEMORY:pvs4jFN [2863] 1436879405.799514: Storing longina(a)N.C.REALM->
> krbtgt/N.C.REALM(a)N.C.REALM in MEMORY:pvs4jFN [2863]
> 1436879405.799566: Creating AP-REP, time 1436879405.736646, subkey
> aes256-cts/7528, seqnum 774738294
>
> [2863] 1436879405.804209: Destroying ccache MEMORY:pvs4jFN
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> After adding to krb5.conf on server [plugins] as you suggested - I could login
> without passwd .
> The difference is in the last line of KRB -part of output:
>
> [plugins]
>
> localauth = {
> module=sssd:/usr/lib/x86_64-linux-
> gnu/sssd/modules/sssd_krb5_localauth_plugin.so
> enable_only = sssd
> }
>
> .....
> [3534] 1436884067.287402: Decrypted AP-REQ with server principal
> lx101$(a)A.C.REALM: aes256-cts/2CCB [3534] 1436884067.287447: AP-REQ
> ticket: longina(a)N.C.REALM -> lx101$(a)A.C.REALM, session key aes256-
> cts/2E16 [3534] 1436884067.358812: Negotiated enctype based on
> authenticator: aes256-cts [3534] 1436884067.358841: Authenticator contains
> subkey: aes256-cts/3DE0 [3534] 1436884067.359004: Resolving unique ccache
> of type MEMORY [3534] 1436884067.359023: Initializing MEMORY:pJb8FBS
> with default princ longina(a)N.C.REALM [3534] 1436884067.359035: Removing
> longina(a)N.C.REALM -> krbtgt/N.C.REALM(a)N.C.REALM from
> MEMORY:pJb8FBS [3534] 1436884067.359045: Storing longina(a)N.C.REALM ->
> krbtgt/N.C.REALM(a)N.C.REALM in MEMORY:pJb8FBS [3534]
> 1436884067.359101: Creating AP-REP, time 1436884067.280266, subkey
> aes256-cts/4AD9, seqnum 458315653
>
> [3534] 1436884067.630732: Initializing
> FILE:/tmp/krb5cc_10002_4NMbBVHudH with default princ
> longina(a)N.C.REALM
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> I must say, that "localauth" is not mentioned in manual for krb5.conf, but
> works! Impossible to figure out by myself!
>
> Thank you very much for help.
>
> Mvh
> Longina
>
>
> > -----Oprindelig meddelelse-----
> > Fra: sssd-users-bounces(a)lists.fedorahosted.org [mailto:sssd-users-
> > bounces(a)lists.fedorahosted.org] På vegne af Sumit Bose
> > Sendt: 13. juli 2015 09:57
> > Til: End-user discussions about the System Security Services Daemon
> > Emne: Re: [SSSD-users] ssh passwordless with sssd-1.12.5
> >
> > On Fri, Jul 10, 2015 at 04:50:39PM +0000, Longina Przybyszewska wrote:
> > > Hi,
> > > .k5login doesn't help . Homedir is mounted with sec=krb5 and not
> > > accessible on ssh server side Until get validated krb principal
> > > credentials -
> > which seems to be my problem.
> >
> > You can use k5login_directory in krb5.conf to use a different
> > directory for testing.
> >
> > >
> > > I have noticed , I have no libpam-krb5 module in PAM I have
> > > libpam-sss module, which seems to be enough to deal with krb
> > > principals for NFS-mounts and GUI logins and ssh logins with passwd.
> > >
> > > With SSSD I can login as 'longina' to machine from @A.C.REALM domain
> > > and
> > get my Kerberos TGT for principal longina(a)N.C.REALM.
> > > Trying SSH - Service tickets nfs/fqdn(a)A.C.REALM and
> > host/fqdn(a)A.C.REALM seem to be ok but user not accepted without
> > passwd.
> > >
> > > SSH should talk to SSSD through PAM , well?
> >
> > In general yes, but for GSSAPI authentication sshd has to do the
> > Kerberos ticket validation on it's own. With recent versions of MIT
> > Kerberos SSSD can help with the principal to username mapping. If your
> > krb5.conf man page says anything about a localauth plugin you can try
> > to add something like
> >
> > [plugins]
> > localauth = {
> > module = sssd:/usr/lib/sssd/modules/sssd_krb5_localauth_plugin.so
> > enable_only = sssd
> >
> > to your krb5.conf. Please note that you have to say 'enable_only =
> > sssd, k5login' is you want to use .k5login files as well.
> >
> > If authentication and user mapping is done and was successful sshd
> > will do the PAM based access control with the help of SSSD.
> >
> > bye,
> > Sumit
> >
> > > Best,
> > > Longina
> > >
> > > > -----Oprindelig meddelelse-----
> > > > Fra: sssd-users-bounces(a)lists.fedorahosted.org [mailto:sssd-users-
> > > > bounces(a)lists.fedorahosted.org] På vegne af Sumit Bose
> > > > Sendt: 10. juli 2015 10:22
> > > > Til: End-user discussions about the System Security Services
> > > > Daemon
> > > > Emne: Re: [SSSD-users] ssh passwordless with sssd-1.12.5
> > > >
> > > > On Thu, Jul 09, 2015 at 04:06:05PM +0000, Longina Przybyszewska
> wrote:
> > > > > Hi,
> > > > > I have SSSD setup with AD as auth/id provider in multi domain
> > > > > trust realm,
> > > > and POSIX attributes in AD for users.
> > > > > With this setup users can use short names (short names match
> > > > sSAMaccount name in AD user object)) for login and get access to
> > > > > their homedir ,NFS mounted with Kerberos security.
> > > > > The "short user names" are unique across domains in realm.
> > > > >
> > > > > Setup works fine, even after recently made possible sssd upgrade
> > > > > to 1.12.5
> > > > (all Linux clients run Ubuntu LTS).
> > > > >
> > > > > We would like to establish passwordless ssh between all
> > > > > AD-integrated
> > > > clients - and have problems.
> > > > > The important detail is, that all machines are in one domain,
> > > > > while
> > users
> > > > can be from other domains inclusive, machine's domain .
> > > > >
> > > > > Until now, passwordless ssh is possible when user and machine
> > > > > are from
> > > > the same domain .
> > > > >
> > > > > Users from domains other than machines's own domain , are asked
> > > > > for
> > > > passwd.
> > > > > All tickets for host and nfs service in user's cache seems to be ok.
> > > > >
> > > > > After debugging ssh/sshd session it seems that connection ssh< -
> > > > > -> sshd
> > > > fails on user authorization.
> > > > > Any ideas?
> > > > >
> > > > >
> > > > > Ssh client side debug:
> > > > > ----------------------------------
> > > > > [9537] 1436450526.619393: Got service principal
> > > > > host/lnx.a.c.realm(a)A.C.REALM [9537] 1436450526.621139: ccselect
> > > > > can't find appropriate cache for server principal
> > > > > host/lnx.a.c.realm(a)A.C.REALM [9537] 1436450526.621254: Getting
> > > > > credentials longina(a)N.C.REALM -> host/lnx.a.c.realm(a)A.C.REALM
> > > > > using ccache FILE:/tmp/krb5cc_XXXXX_CN76dg [9537]
> > 1436450526.621355:
> > > > > Retrieving longina(a)N.C.REALM -> host/lnx.a.c.realm(a)A.C.REALM
> > > > > from FILE:/tmp/krb5cc_XXXXX_CN76dg with result: 0/Success [9537]
> > > > > 1436450526.621490: Creating authenticator for longina(a)N.C.REALM
> > > > > -> host/lnx.a.c.realm(a)A.C.REALM, seqnum 1059254370, subkey
> > > > > aes256-cts/4255, session key aes256-cts/2F16
> > > > > debug2: we sent a gssapi-with-mic packet, wait for reply
> > > > > debug1: Authentications that can continue:
> > > > > publickey,gssapi-keyex,gssapi-with-mic,password
> > > > > [9537] 1436450526.623050: Convert service host (service with
> > > > > host as
> > > > > instance) on host lnx.a.c.realmto principal [9537] 1436450526.624716:
> > > > > Remote host after forward canonicalization: lnx.a.c.realm [9537]
> > > > > 1436450526.624760: Remote host after reverse DNS processing:
> > > > > lnx.a.c.realm [9537] 1436450526.624793: Got service principal
> > > > > host/lnx.a.c.realm(a)A.C.REALM [9537] 1436450526.626601: ccselect
> > > > > can't find appropriate cache for server principal
> > > > > host/lnx.a.c.realm(a)A.C.REALM [9537] 1436450526.626719: Getting
> > > > > credentials longina(a)N.C.REALM -> host/lnx.a.c.realm(a)A.C.REALM
> > > > > using ccache FILE:/tmp/krb5cc_XXXXX_CN76dg [9537]
> > 1436450526.626821:
> > > > > Retrieving longina(a)N.C.REALM -> host/lnx.a.c.realm(a)A.C.REALM
> > > > > from FILE:/tmp/krb5cc_XXXXX_CN76dg with result: 0/Success [9537]
> > > > > 1436450526.626984: Getting credentials longina(a)N.C.REALM ->
> > > > > host/lnx.a.c.realm(a)A.C.REALM using ccache
> > > > > FILE:/tmp/krb5cc_XXXXX_CN76dg [9537] 1436450526.627067:
> > > > > Retrieving longina(a)N.C.REALM -> host/lnx.a.c.realm(a)A.C.REALM
> > > > > from FILE:/tmp/krb5cc_XXXXX_CN76dg with result: 0/Success [9537]
> > > > > 1436450526.627162: Creating authenticator for longina(a)N.C.REALM
> > > > > -> host/lnx.a.c.realm(a)A.C.REALM, seqnum 778106202, subkey
> > > > > aes256-cts/CBE6, session key aes256-cts/2F16
> > > > > debug2: we sent a gssapi-with-mic packet, wait for reply
> > > > > debug1: Authentications that can continue:
> > > > > publickey,gssapi-keyex,gssapi-with-mic,password
> > > > > debug2: we did not send a packet, disable method
> > > > > debug3: authmethod_lookup publickey
> > > > >
> > > > >
> > > > > sshd server side debug:
> > > > > ------------------------------------
> > > > > ....
> > > > > debug2: input_userauth_request: setting up authctxt for longina
> > > > > [preauth]
> > > > > debug3: mm_start_pam entering [preauth]
> > > > > debug3: mm_request_send entering: type 100 [preauth]
> > > > > debug3: mm_inform_authserv entering [preauth]
> > > > > debug3: mm_request_send entering: type 4 [preauth]
> > > > > debug2: input_userauth_request: try method none [preauth]
> > > > > debug3: userauth_finish: failure partial=0 next
> > > > > methods="publickey,gssapi-keyex,gssapi-with-mic,password"
> > > > > [preauth]
> > > > > debug3: mm_request_receive entering
> > > > > debug3: monitor_read: checking request 100
> > > > > debug1: PAM: initializing for "longina"
> > > > > debug1: PAM: setting PAM_RHOST to "10.80.8.108"
> > > > > debug1: PAM: setting PAM_TTY to "ssh"
> > > > > debug2: monitor_read: 100 used once, disabling now
> > > > > debug3: mm_request_receive entering
> > > > > debug3: monitor_read: checking request 4
> > > > > debug3: mm_answer_authserv: service=ssh-connection, style=,
> > > > > role=
> > > > > debug2: monitor_read: 4 used once, disabling now
> > > > > debug1: userauth-request for user longina service ssh-connection
> > > > > method gssapi-with-mic [preauth]
> > > > > debug1: attempt 1 failures 0 [preauth]
> > > > > debug2: input_userauth_request: try method gssapi-with-mic
> > > > > [preauth]
> > > > > debug3: mm_request_send entering: type 42 [preauth]
> > > > > debug3: mm_request_receive_expect entering: type 43 [preauth]
> > > > > debug3: mm_request_receive entering [preauth]
> > > > > debug3: mm_request_receive entering
> > > > > debug3: monitor_read: checking request 42
> > > > > debug3: mm_request_send entering: type 43 Postponed
> > > > > gssapi-with-mic for longina from 10.80.8.108 port 53479 ssh2
> > > > > [preauth]
> > > > > debug3: mm_request_send entering: type 44 [preauth]
> > > > > debug3: mm_request_receive_expect entering: type 45 [preauth]
> > > > > debug3: mm_request_send entering: type 47 Failed gssapi-with-mic
> > > > > for longina from 10.80.8.108 port 53479 ssh2
> > > > > debug3: mm_ssh_gssapi_userok: user not authenticated [preauth]
> > > >
> > > > Chances are that mapping the Kerberos principal to the local user
> > > > name
> > fails.
> > > >
> > > > Since the Kerberos ticket only contains the Kerberos principal and
> > > > it is not desirable that any user with a valid Kerberos ticket can
> > > > log in as any local user the Kerberos client library has to do
> > > > some mapping between the Kerberos principal and the local user
> name.
> > > >
> > > > There are various mapping schemes available. For testing
> > > > (especially since I'm not too familiar with Kerberos on Ubuntu) I
> > > > would recommend to create a .k5login file in the home directory of
> > > > the user you want to log in as. The .k5login file should contain
> > > > the Kerberos principal which should be allowed to log in as this
> > > > user, e.g. longina(a)N.C.REALM in your case (please note that
> > > > Kerberos is case-sensitive). Please check permissions on .k5login
> > > > as well, only the
> > user itself should be able to access it.
> > > >
> > > > If this works but you don't want to add a .k5login file for every
> > > > user please tell me which Kerberos version is used on your Ubuntu
> > > > system to see which other schemes are available.
> > > >
> > > > HTH
> > > >
> > > > bye,
> > > > Sumit
> > > >
> > > >
> > >
> > > _______________________________________________
> > > sssd-users mailing list
> > > sssd-users(a)lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
> > _______________________________________________
> > sssd-users mailing list
> > sssd-users(a)lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
8 years, 4 months
[KE1033238] Unable to resolve User IDs from trusted Domain
by Paul Becker
Dear Sir or Madam,
my college configured an external trust for our existing Active Directory. We have joined our Linux Server using realmd and aren't able resolving any user IDs from the new trusted domain using sssd. I am in fact able to get a Kerberos Ticket with credentials of the trusted domain. Is this a known issue? Please let me know if I am able to provide any futher information. Logfiles are attached to this mail.
System requirements:
- centos7 with sssd 1.12.2-58 joined to active directory domain 'content.zone'. 'content.zone' in turn trusts (one-way, external) the domain 'oew.de'.
Symptoms:
- 'id user(a)oew.de' gives the error message ' GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)]'
- resolving user(a)content.zone works without a hitch.
Error Message:
(Thu Jul 30 09:07:28 2015) [sssd[be[content.zone]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)]
How to reproduce:
sudo realm join --user="administrator" --computer-ou=OU=Computers,OU=CAP,DC=content,DC=zone content.zone
sudo systemctl stop sssd; sudo rm -rf /var/lib/sss/db/*; sudo systemctl start sssd
id administrator(a)oew.de
Regards,
Paul Becker
8 years, 4 months
sudo - multiple domains - same username
by Cumer Cristiano
Hello,
I have a setup with two different AD domains a.com and b.com in separate forests. Im working with sssd-1.11.7
Everything is fine apart from sudo. When I issue an sudo, sssd performs authentications always on domain A even if the user logged in belongs to domain B.
How can I tell sssd to perform the searches in the domain of the logged in user?
Cristiano
8 years, 4 months
sudo very slow
by Ray Van Dolson
Actually, numerous things are slow (including logins), but the sudo
example is quite easy to reproduce. Am new to SSSD so I'm assuming
this is something I've misconfigured.
Here's my config:
[sssd]
config_file_version = 2
domains = domain.com
services = nss, pam
debug_level = 0
override_space = _
[nss]
debug_level = 0
override_shell = /bin/bash
allowed_shells = /bin/bash, /bin/tcsh
vetoed_shells = /bin/csh
shell_fallback = /bin/bash
[pam]
debug_level = 0
[domain/domain.com]
debug_level = 0
id_provider = ad
; access_provider = ad
; ad_access_filter = memberOf=CN=ISTUnix,DC=domain,DC=com
access_provider = simple
simple_allow_groups = istunix
krb5_realm = DOMAIN.COM
override_homedir = /home/%u
ldap_referrals = false
sudoers is fairly simple -- just defaults save for the following:
%istunix ALL=(ALL) NOPASSWD: ALL
However, when I run 'sudo su -' as a test, it can take 20+ seconds for
it to succeed. Debug logs seem to show SSSD querying many groups. I
can post debug logs if someone thinks they'll be useful -- but am
hoping there's some obvious best practice I'm missing.
Side note that I kind of prefer using access_provider = ad above in
tandem with ad_access_filter as it's 'faster' for most logins (once the
info is cached it's faster). It seems that via the simple access
provider, logins are slower (I think it queries all groups?). However,
doesn't seem that ad_access_filter handles nested groups at all....
Thanks!
Ray
8 years, 4 months
sssd-be crash
by Christian Tardif
Hi,
I have sssd installed on kubuntu 15.04, installed and configured sssd as
I used to do on any other distros I'm managing, and it crashes when I
have enumerate set to true. On normal ciscumstances, I could have it set
to false but this is a desktop environment, and I need to have all the
users listed on Simple Desktop Display Manager. How could I achieve this
and stop sssd from crashing ?
Thanks,
--------------------------------------------------------------------------------
Christian Tardif
8 years, 4 months