sssd-users August 2014

sssd-users@lists.fedorahosted.org

27 participants
36 discussions

disjointed AD namespace
by Daniel Shown 14 Aug '14

14 Aug '14

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

2 2

LDAP and useradd, groupmod, passwd, etc.
by Jacob Weber 13 Aug '14

13 Aug '14

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

2 1

FW: NFS+KERB+SSSD Ubuntu 14.04
by Longina Przybyszewska 12 Aug '14

12 Aug '14

>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

2 4

how to map unix group name to other attribute than "cn" of the group entry
by XuQing Tan 12 Aug '14

12 Aug '14

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 | ------------------------------------

5 15

Externally defined, cross-domain group membership. Prohibited?
by Nordgren, Bryce L -FS 11 Aug '14

11 Aug '14

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.

2 2

NFS+KERB+SSSD Ubuntu 14.04
by Longina Przybyszewska 11 Aug '14

11 Aug '14

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

3 9

Merging local/ldap groups
by Jacob Weber 08 Aug '14

08 Aug '14

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

3 3

Re: [SSSD-users] Merging local/ldap groups
by Jacob Weber 08 Aug '14

08 Aug '14

> 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

1 0

Merging local/ldap groups
by Jacob Weber 08 Aug '14

08 Aug '14

> 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

2 1

SSSD (1.11.6 with LDAP/Krb5 providers) Init group lookup failed.
by 杉山昌治 08 Aug '14

08 Aug '14

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

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users August 2014