disjointed AD namespace
by Daniel Shown
I'm having trouble authenticating to an AD domain with a disjointed
namespace using SSSD. Here's what I'm up against:
netbios domain name: BLAH
domain (& kerberos realm): DS.BLAH.COM
UPNs: username(a)BLAH.COM
to join to the domain I have to have workgroup: BLAH in smb.conf, which is
not generally how smb and winbind are config'ed (usually it would be DS
instead of BLAH).
I can create a kerberos ticket for user(a)DS.BLAH.COM.
I can do an "id user(a)ds.blah.com" and get valid response.
but when I try to "su user(a)ds.blah.com" I get an invalid password, and a
log entry indicating "[sssd[krb5_child[29198]]]: Cannot resolve servers for
KDC in realm "BLAH.COM"". I'm assuming that it's looking for the KDC there
because of the setting in smb.conf.
I'm running SSSD 1.9.2 on CentOS 6.5.
I've tried various settings googling around, and so my current sssd.conf
file looks like:
[sssd]
services = nss, pam, ssh, pac
config_file_version = 2
domains = ds.blah.com
debug_level = 10
[nss]
[pam]
[sudo]
[autofs]
[ssh]
[pac]
[domain/ds.blah.com]
cache_credentials = False
krb5_store_password_if_offline = False
id_provider = ad
auth_provider = ad
access_provider = ad
ad_server = dc1.ds.blah.com
ad_hostname = host.ds.blah.com
krb5_realm = DS.BLAH.COM
ad_domain = ds.blah.com
ad_enable_dns_sites = True
krb5_canonicalize = false
debug_level = 5
Any suggestions would be greatly appreciated.
===================================
*Daniel Shown,*
Linux Systems Administrator
Advanced Technology Group
Information Technology Services <http://www.slu.edu/its>
at Saint Louis University <http://www.slu.edu/>.
314-977-2583
===================================
"The aim of education
is the knowledge,
not of facts,
but of values."
— William S. Burroughs
"I’m supposed to be
a scientific person
but I use intuition
more than logic
in making basic
decisions."
— Seymour R. Cray
9 years, 8 months
LDAP and useradd, groupmod, passwd, etc.
by Jacob Weber
If I use SSSD on CentOS with an LDAP domain, do tools like useradd, groupmod, and passwd affect LDAP users/groups, or do they only affect the ones in /etc/passwd and /etc/group?
I'd prefer the latter, but I'm not sure whether this is something that can be configured. I know there are also luseradd and lgroupmod, but I'm using a tool (Ansible) that relies on the standard commands.
Thanks,
Jacob
9 years, 8 months
FW: NFS+KERB+SSSD Ubuntu 14.04
by Longina Przybyszewska
>I fail to see how SSSD can be to blame for any of this, as the mount has nothing to do with mapping users.
I don't blame SSSD either ;)
The only context to SSSD could be - joining computers to AD - as I joined both computers with 'realmd' method recommended by SSSD team.
The Kerberos keys created by realm are good enough for authentication users with SSSD.
'Realm' does not support adding SPN principal into AD ; To create nfs principal for server I used method described in
https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server with the following commands:
setspn -A nfs/jota.nat.c.example.com jota
ktpass /princ nfs/jota.nat.c.example.com(a)NAT.C.EXAMPLE.COM /out jota-nfs-2.keytab /crypto all /ptype KRB5_NT_PRINCIPAL -desonly /mapuser NAT-EXAMPLE\JOTA$ -setupn -setpass +rndPass +answer
(NAT-EXAMPLE in my case is short AD domain name)
I added keytab for nfs principal to the NFS server's /etc/krb5.keytab
root@jota:/# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
4 host/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (des-cbc-crc)
4 host/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (des-cbc-md5)
4 host/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (aes128-cts-hmac-sha1-96)
4 host/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (aes256-cts-hmac-sha1-96)
4 host/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (arcfour-hmac)
4 host/JOTA(a)NAT.C.SDU.DK (des-cbc-crc)
4 host/JOTA(a)NAT.C.SDU.DK (des-cbc-md5)
4 host/JOTA(a)NAT.C.SDU.DK (aes128-cts-hmac-sha1-96)
4 host/JOTA(a)NAT.C.SDU.DK (aes256-cts-hmac-sha1-96)
4 host/JOTA(a)NAT.C.SDU.DK (arcfour-hmac)
4 JOTA$(a)NAT.C.SDU.DK (des-cbc-crc)
4 JOTA$(a)NAT.C.SDU.DK (des-cbc-md5)
4 JOTA$(a)NAT.C.SDU.DK (aes128-cts-hmac-sha1-96)
4 JOTA$(a)NAT.C.SDU.DK (aes256-cts-hmac-sha1-96)
4 JOTA$(a)NAT.C.SDU.DK (arcfour-hmac)
4 nfs/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (des-cbc-crc)
4 nfs/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (des-cbc-md5)
4 nfs/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (arcfour-hmac)
4 nfs/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (aes256-cts-hmac-sha1-96)
4 nfs/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (aes128-cts-hmac-sha1-96)
...and I am getting persistent "Permission denied " on client.
Version of nfs-utils Is the same:
root@jota:/home/alongina# dpkg -l | grep nfs
ii libnfsidmap2:amd64 0.25-5 amd64 NFS idmapping library
ii nfs-common 1:1.2.8-6ubuntu1.1 amd64 NFS support files common to client and server
ii nfs-kernel-server 1:1.2.8-6ubuntu1.1 amd64 support for NFS kernel server
>I've always gone for an nfs/fqn userPrincipal for both client and server, which I understand to be a touch outdated with current nfs-utils. If you're using AD, it's also important to set the >userAccountControl to limit the kerberos tickets to not include PAC, or else you'll have issues with user accounts that are members of a significant number of groups.
>I think the significant bit is "Wrong principal in request" on the server.
>Possibly things to check:
>Check kvno lines up correctly for all machine credentials. When in doubt, delete the machine objects and start again.
Kvno seems to be OK ; (SSSD could be the proof)
>Previously NFS was very limited in what enctypes it could cope with. Try again with:
>[libdefaults]
>default_tkt_enctypes = arcfour-hmac
I added that option to /etc/krb5.conf (on both, and rebooted both);
Still permission denied...
ON client:
Output from rpc.gssd after issuing 'mount' command
--------------------------------
Success getting keytab entry for 'JEDI$(a)NAT.C.EXAMPLE.COM'
INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM' are good until 1407800571
INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM' are good until 1407800571
using FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM as credentials cache for machine creds
using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM
creating context using fsuid 0 (save_uid 0)
creating tcp client for server jota.nat.c.example.com
DEBUG: port already set to 2049
creating context with server nfs(a)jota.nat.c.example.com
WARNING: Failed to create krb5 context for user with uid 0 for server jota.nat.c.example.com
WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM for server jota.nat.c.example.com
WARNING: Machine cache is prematurely expired or corrupted trying to recreate cache for server jota.nat.c.example.com
Full hostname for 'jota.nat.c.example.com' is 'jota.nat.c.example.com'
Full hostname for 'jedi.nat.c.example.com' is 'jedi.nat.c.example.com'
Success getting keytab entry for 'JEDI$(a)NAT.C.EXAMPLE.COM'
INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM' are good until 1407800571
INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM' are good until 1407800571
using FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM as credentials cache for machine creds
using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM
creating context using fsuid 0 (save_uid 0)
creating tcp client for server jota.nat.c.example.com
DEBUG: port already set to 2049
creating context with server nfs(a)jota.nat.c.example.com
WARNING: Failed to create krb5 context for user with uid 0 for server jota.nat.c.example.com
WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM for server jota.nat.c.example.com
WARNING: Failed to create machine krb5 context with any credentials cache for server jota.nat.c.example.com
doing error downcall
Kerberos cache on the client:
root@jedi:/home/longinap# klist -ce /tmp/krb5ccmachine_NAT.C.EXAMPLE.COM
Ticket cache: FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM
Default principal: JEDI$(a)NAT.C.EXAMPLE.COM
Valid starting Expires Service principal
08/11/2014 15:42:51 08/12/2014 01:42:51 krbtgt/NAT.C.EXAMPLE.COM(a)NAT.C.EXAMPLE.COM
renew until 08/12/2014 15:42:51, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
08/11/2014 15:42:51 08/12/2014 01:42:51 nfs/jota.nat.c.example.com(a)NAT.C.EXAMPLE.COM
renew until 08/12/2014 15:42:51, Etype (skey, tkt): arcfour-hmac, arcfour-hmac
-------------------
Encryption mismatch?
Principal mismach?
!"#¤%&!
--
Longina
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
9 years, 8 months
how to map unix group name to other attribute than "cn" of the group entry
by XuQing Tan
Hi Folks
in our project, there is already one legacy openldap server runing.
we managed the user and groups with posixAccount and posixGroup.
recently, we setup ssh ldap integration with sssd, we can login to the
linux box with ldap user credentials, so far so good.
except one thing, we found there are some groups name are too long (large
than 32 char) which violate the 32 char unix group name length contraints
according to "groupadd" man page.
we can't modiy the attribute "cn" of posixGroup since it's already used in
other integrated system.
so i'm wondering, is there any way to map the unix group name to something
else, rather than the defualt attribute "cn"?
i did search the sssd conf manual, nothing found, so i'd like to consult
you here.
Thanks & Best Regards!
///
(. .)
--------ooO--(_)--Ooo--------
| Nick Tan |
------------------------------------
9 years, 8 months
Externally defined, cross-domain group membership. Prohibited?
by Nordgren, Bryce L -FS
I have an external LDAP metadirectory acting as an identity provider for my linux domain. The metadirectory overrides and supplements the upstream identity source (e.g., it passes thru sn, givenName, mail, telephoneNumber; but overrides or adds uidNumber, gidNumber, loginShell, etc.) The directory also holds RFC2307 group information, and the groups contain members from multiple upstream sources. Authentication via simple bind (for web apps) is passed thru to the relevant upstream provider. LDAP works great.
For command line login, I want to use Kerberos. Each upstream provider is configured as a domain within sssd which uses LDAP for identities and Kerberos for authentication. The local, linux domain-wide groups are included as one of the domain definitions, but not the others. For instance, I have defined domain A, B, and C. Domain A contains group information having members from all three. Domains B and C essentially have no groups defined.
"Getent passwd user works." Authentication works. "getent group test" works, initially...SSSD is removing users from my group. sss_cache -G restores the user (i.e., getent group test includes the user), but the first time the user tries to exercise their permissions by accessing a file on the filesystem, they get a permission denied and are removed from the group (getent group test does not include the user).
Are cross-realm groups something that sssd is designed to prohibit?
This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
9 years, 8 months
NFS+KERB+SSSD Ubuntu 14.04
by Longina Przybyszewska
Hi,
I really struggle with "permission denied" while mounting NFS share with sec=krb5;
Both machines(Ubuntu 14.04) , NFS client and server are configured with SSSD, and authentication seems to work (only one test user for configuration with PoSIX ids ;)
'getent passwd longina' returns correct values on both.
I joined both machines to AD with 'realmd', and additionaly created SPN principal nfs/jota.nat.c.example.com(a)NAT.C.EXAMPLE.COM with setspn.exe on AD
and added keys to the /etc/krb5.keytab .
I expect to be able to mount NFS share with sec=krb5 as root on client using machine credentials.
HERE some debugging output
Output on client (jedi) from 'rpc.gssd' while mounting nfs share
-----------------
doing error downcall
handling gssd upcall (/run/rpc_pipefs/nfs/clnt9)
handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 '
handling krb5 upcall (/run/rpc_pipefs/nfs/clnt9)
process_krb5_upcall: service is '<null>'
Full hostname for 'jota.nat.c.sdu.dk' is 'jota.nat.c.sdu.dk'
Full hostname for 'jedi.nat.c.sdu.dk' is 'jedi.nat.c.sdu.dk'
Success getting keytab entry for 'JEDI$(a)NAT.C.SDU.DK'
INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_NAT.C.SDU.DK' are good until 1407542806
INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_NAT.C.SDU.DK' are good until 1407542806
using FILE:/tmp/krb5ccmachine_NAT.C.SDU.DK as credentials cache for machine creds
using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_NAT.C.SDU.DK
creating context using fsuid 0 (save_uid 0)
creating tcp client for server jota.nat.c.sdu.dk
DEBUG: port already set to 2049
creating context with server nfs(a)jota.nat.c.sdu.dk
WARNING: Failed to create krb5 context for user with uid 0 for server jota.nat.c.sdu.dk
WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5ccmachine_NAT.C.SDU.DK for server jota.n\
at.c.sdu.dk
WARNING: Machine cache is prematurely expired or corrupted trying to recreate cache for server jota.nat.c.sdu.dk
Full hostname for 'jota.nat.c.sdu.dk' is 'jota.nat.c.sdu.dk'
Full hostname for 'jedi.nat.c.sdu.dk' is 'jedi.nat.c.sdu.dk'
Success getting keytab entry for 'JEDI$(a)NAT.C.SDU.DK'
INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_NAT.C.SDU.DK' are good until 1407542806
INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_NAT.C.SDU.DK' are good until 1407542806
using FILE:/tmp/krb5ccmachine_NAT.C.SDU.DK as credentials cache for machine creds
using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_NAT.C.SDU.DK
creating context using fsuid 0 (save_uid 0)
creating tcp client for server jota.nat.c.sdu.dk
DEBUG: port already set to 2049
creating context with server nfs(a)jota.nat.c.example.com
WARNING: Failed to create krb5 context for user with uid 0 for server jota.nat.c.example.com
WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM for server jota.n\
at.c.example.com
WARNING: Failed to create machine krb5 context with any credentials cache for server jota.nat.c.example.com
doing error downcall
destroying client /run/rpc_pipefs/nfs/clnta
destroying client /run/rpc_pipefs/nfs/clnt9
-----------
client(jedi):
hostname:
jedi
----------
root@jedi:/var/lib/sss/db# klist -c
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)
root@jedi:/var/lib/sss/db# klist -c /tmp/krb5ccmachine_NAT.C.EXAMPLE.COM
Ticket cache: FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM
Default principal: JEDI$(a)NAT.C.EXAMPLE.COM
Valid starting Expires Service principal
08/08/2014 16:06:46 08/09/2014 02:06:46 krbtgt/NAT.C.EXAMPLE.COM(a)NAT.C.EXAMPLE.COM
renew until 08/09/2014 16:06:46
08/08/2014 16:06:46 08/09/2014 02:06:46 nfs/jota.nat.c.example.com(a)NAT.C.EXAMPLE.COM
renew until 08/09/2014 16:06:46
root@jedi:/var/lib/sss/db# klist -ce /tmp/krb5ccmachine_NAT.C.EXAMPLE.COM
Ticket cache: FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM
Default principal: JEDI$(a)NAT.C.EXAMPLE.COM
Valid starting Expires Service principal
08/08/2014 16:06:46 08/09/2014 02:06:46 krbtgt/NAT.C.EXAMPLE.COM(a)NAT.C.EXAMPLE.COM
renew until 08/09/2014 16:06:46, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
08/08/2014 16:06:46 08/09/2014 02:06:46 nfs/jota.nat.c.example.com(a)NAT.C.EXAMPLE.COM
renew until 08/09/2014 16:06:46, Etype (skey, tkt): arcfour-hmac, arcfour-hmac
------------
root@jedi:/etc# klist -ek
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
6 host/jedi.nat.c.example.com(a)NAT.C.EXAMPLE.COM (des-cbc-crc)
6 host/jedi.nat.c.example.com(a)NAT.C.EXAMPLE.COM (des-cbc-md5)
6 host/jedi.nat.c.example.com(a)NAT.C.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
6 host/jedi.nat.c.example.com(a)NAT.C.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
6 host/jedi.nat.c.example.com(a)NAT.C.EXAMPLE.COM (arcfour-hmac)
6 host/JEDI(a)NAT.C.EXAMPLE.COM (des-cbc-crc)
6 host/JEDI(a)NAT.C.EXAMPLE.COM (des-cbc-md5)
6 host/JEDI(a)NAT.C.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
6 host/JEDI(a)NAT.C.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
6 host/JEDI(a)NAT.C.EXAMPLE.COM (arcfour-hmac)
6 JEDI$(a)NAT.C.EXAMPLE.COM (des-cbc-crc)
6 JEDI$(a)NAT.C.EXAMPLE.COM (des-cbc-md5)
6 JEDI$(a)NAT.C.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
6 JEDI$(a)NAT.C.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
6 JEDI$(a)NAT.C.EXAMPLE.COM (arcfour-hmac)
-------------------------
Server (jota):
---------------------
hostname:
jota.nat.c.example.com
-------
root@jota:/home/alongina# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
4 nfs/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (des-cbc-crc)
4 nfs/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (des-cbc-md5)
4 nfs/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (arcfour-hmac)
4 nfs/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (aes256-cts-hmac-sha1-96)
4 nfs/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (aes128-cts-hmac-sha1-96)
4 host/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (des-cbc-crc)
4 host/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (des-cbc-md5)
4 host/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (aes128-cts-hmac-sha1-96)
4 host/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (aes256-cts-hmac-sha1-96)
4 host/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (arcfour-hmac)
4 host/JOTA(a)NAT.C.SDU.DK (des-cbc-crc)
4 host/JOTA(a)NAT.C.SDU.DK (des-cbc-md5)
4 host/JOTA(a)NAT.C.SDU.DK (aes128-cts-hmac-sha1-96)
4 host/JOTA(a)NAT.C.SDU.DK (aes256-cts-hmac-sha1-96)
4 host/JOTA(a)NAT.C.SDU.DK (arcfour-hmac)
4 JOTA$(a)NAT.C.SDU.DK (des-cbc-crc)
4 JOTA$(a)NAT.C.SDU.DK (des-cbc-md5)
4 JOTA$(a)NAT.C.SDU.DK (aes128-cts-hmac-sha1-96)
4 JOTA$(a)NAT.C.SDU.DK (aes256-cts-hmac-sha1-96)
4 JOTA$(a)NAT.C.SDU.DK (arcfour-hmac)
root@jota:/# ps ax | grep rpc
512 ? Ss 0:00 rpcbind
625 ? Ss 0:00 rpc.statd -L
670 ? S< 0:00 [rpciod]
769 ? Ss 0:00 rpc.idmapd
850 ? Ss 0:00 rpc.gssd
2348 ? Ss 0:00 /usr/sbin/rpc.svcgssd -vvvvvvvvvv
2350 ? Ss 0:00 /usr/sbin/rpc.mountd --manage-gids
root@jota:/home/alongina# klist -c
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)
--------------
root@jota:/home/alongina# cat /etc/exports
#
/nfs *(rw,crossmnt,no_subtree_check,sec=krb5:krb5p:krb5i)
----------------
root@jota:/home/alongina# kinit -k JOTA\$(a)NAT.C.EXAMPLE.COM
---------------
root@jota:/home/alongina# klist -c
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: JOTA$(a)NAT.C.EXAMPLE.COM
Valid starting Expires Service principal
08/08/14 16:36:44 09/08/14 02:36:44 krbtgt/NAT.C.EXAMPLE.COM(a)NAT.C.EXAMPLE.COM
renew until 09/08/14 16:36:44
/var/log/syslog (rpc.svcgssd)
Aug 8 16:34:56 jota rpc.svcgssd[2348]: finished handling null request
Aug 8 16:34:56 jota rpc.svcgssd[2348]: entering poll
Aug 8 16:34:56 jota rpc.svcgssd[2348]: leaving poll
Aug 8 16:34:56 jota rpc.svcgssd[2348]: handling null request
Aug 8 16:34:56 jota rpc.svcgssd[2348]: svcgssd_limit_krb5_enctypes: Calling gss_set_allowable_enctypes with 7 enctypes from the kernel
Aug 8 16:34:56 jota rpc.svcgssd[2348]: WARNING: gss_accept_sec_context failed
Aug 8 16:34:56 jota rpc.svcgssd[2348]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Wrong principal in request
Aug 8 16:34:56 jota rpc.svcgssd[2348]: sending null reply
Mange hilsner
Longina
9 years, 8 months
Merging local/ldap groups
by Jacob Weber
Is it possible to merge a group that's defined locally with one defined on an LDAP server?
I'm running a Subversion server. I need certain local users like apache to have write access to the repository files. But I also need my LDAP users to be able to write to them.
I was thinking of creating a local group in /etc/group, containing the local users. Then I'd create a group on the LDAP server with the same name and numeric ID, containing the LDAP users. The repository files would then be assigned to that group, so they're writable by both sets of users. Is that a bad idea?
Thanks,
Jacob
9 years, 8 months
Re: [SSSD-users] Merging local/ldap groups
by Jacob Weber
> Only one local user needs access? Can it be owned by apache and writeable by the LDAP group?
>
> Filesystem ACLs let you specify two groups, will that work?
>
> Intentionally creating a GID collision at the scope of the local machine does not appear to have solved your problem, so I'd undo that right away.
It's probably going to be more than one user. I'm thinking ACLs might be the way to go.
Jacob
9 years, 8 months
Merging local/ldap groups
by Jacob Weber
> if you're using the RFC2307 schema (and not RFC2307bis) then it's
> possible to just include a local user in the memberUid attribute. See:
Thanks...unfortunately I'm using RFC2307bis, so that won't work.
Jacob
9 years, 8 months
SSSD (1.11.6 with LDAP/Krb5 providers) Init group lookup failed.
by 杉山昌治
Hello
I also have a group issue on sssd 1.11.6 with LDAP/Krb5 provider.
When I used sssd-1.9.2-129.el6_5.4.x86_64, I could get all belonging
groups by "id" command.
After I updated to sssd-1.11.6-1, I could get only primary group by
"id" command.
I needed to retrieve each group information by "getent group" command,
After that I could get all belonging groups by "id" command.
It looks like the initial group lookup failed on sssd-1.11.6-1.
Is this behavior a bug or spec of version 1.11.6 or I missed something
in configuration file ?
I would appreciate your kind support.
Reproduce Procedures
================
1. Set up desired sssd version
2. Remove cache files
# rm -f /var/lib/sss/db/cache*
3. Start sssd
# sssd -i -d7 -c sssd.conf-LDAP
4. Check account information by "id" command
# id shoji-lab
5. Check group information by "getent group" command
# getent group G-Role-ISOps-Server
6. Check account information again.
# id shoji-lab
Test Result (sssd-1.9.2-129)
====================
[admin@jpbl0-in00-is16 ~]$ rpm -q sssd
sssd-1.9.2-129.el6_5.4.x86_64
[admin@jpbl0-in00-is16 ~]$ id shoji-lab
uid=20000(shoji-lab) gid=20002(Domain Users) groups=20002(Domain
Users),20166(U-Role-ISOps-Server),20165(G-Role-ISOps-Server)
[admin@jpbl0-in00-is16 ~]$ getent group G-Role-ISOps-Server
G-Role-ISOps-Server:*:20165:shoji-lab,bmulvany-lab,banban-lab,test_shoji,mokbrian-lab,arionk-lab,bleej-lab,haughtoj-lab,tstevens-lab,dkeane-lab,danoneil-lab,srpenn-lab
[admin@jpbl0-in00-is16 ~]$ id shoji-lab
uid=20000(shoji-lab) gid=20002(Domain Users) groups=20002(Domain
Users),20166(U-Role-ISOps-Server),20165(G-Role-ISOps-Server)
Test Result (sssd-1.11.6-1)
====================
[admin@jpbl0-in00-is16 ~]$ id shoji-lab
uid=20000(shoji-lab) gid=20002(Domain Users) groups=20002(Domain Users)
[admin@jpbl0-in00-is16 ~]$ getent group G-Role-ISOps-Server
G-Role-ISOps-Server:*:20165:shoji-lab,bmulvany-lab,banban-lab,test_shoji,mokbrian-lab,arionk-lab,bleej-lab,haughtoj-lab,tstevens-lab,dkeane-lab,danoneil-lab,srpenn-lab
[admin@jpbl0-in00-is16 ~]$ id shoji-lab
uid=20000(shoji-lab) gid=20002(Domain Users) groups=20002(Domain
Users),20165(G-Role-ISOps-Server)
Error Log Summary (sssd-1.11.6-1)
==========================
(Fri Aug 8 03:30:18 2014) [sssd[nss]] [nss_memcache_initgr_check]
(0x1000): Got request for [shoji-lab@labsso]
(Fri Aug 8 03:30:18 2014) [sssd[nss]] [sss_dp_get_reply] (0x1000):
Got reply from Data Provider - DP error code: 3 errno: 22 error
message: Init group lookup failed
(Fri Aug 8 03:30:18 2014) [sssd[nss]] [nss_cmd_getby_dp_callback]
(0x0040): Unable to get information from Data Provider
Error: 3, 22, Init group lookup failed
Will try to return what we have in cache
(Fri Aug 8 03:30:18 2014) [sssd[nss]] [sss_dp_req_destructor]
(0x0400): Deleting request: [0x418450:3:shoji-lab@labsso]
(Fri Aug 8 03:30:18 2014) [sssd[be[labsso]]] [acctinfo_callback]
(0x0100): Request processed. Returned 3,22,Init group lookup failed
(Fri Aug 8 03:30:18 2014) [sssd[nss]] [client_recv] (0x0200): Client
disconnected!
SSSD Configuration : Using LDAP/Krb5 providers
====================================
[sssd]
config_file_version = 2
services = nss, pam, sudo
domains = labsso
[nss]
[pam]
[sudo]
[domain/labsso]
enumerate = false
ldap_id_use_start_tls = False
id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
krb5_realm = LABSSO.LABROOT.ISOPS.EXAMPLE.COM
krb5_server = jpbw0-in00-is82.labsso.labroot.isops.example.com
krb5_kpasswd = jpbw0-in00-is82.labsso.labroot.isops.example.com
ldap_schema = rfc2307bis
ldap_force_upper_case_realm = True
ldap_user_object_class = person
ldap_group_object_class = group
ldap_user_gecos = displayName
ldap_user_home_directory = unixHomeDirectory
ldap_uri = ldap://jpbw0-in00-is82.labsso.labroot.isops.example.com
ldap_search_base = DC=labsso,DC=labroot,DC=isops,DC=example,DC=com
ldap_default_bind_dn = bindisops-lab(a)labsso.labroot.isops.example.com
ldap_default_authtok_type = password
ldap_default_authtok = password
ldap_referrals = False
LDAP Server (Active Directory) User/Group Hierarchy
========================================
shoji-lab (uid=20000, @LABSSO)
G-Role-ISOps-Server (gid=20165, @LABSSO)
U-Role-ISOps-Server (gid=20166, @LABSSO)
Regards,
Shoji Sugiyama
9 years, 8 months
