Trying to use sssd to connect to large AD service - secondary groups not loading
by Robert Sturrock
Hi All.
I'm struggling a bit trying to get sssd (client is RHEL7.2, so using sssd-1.13.0-40.el7_2.1.x86_64) to connect to a large institutional AD (100k+ users, each user belonging to dozens or even hundreds of groups). I'm following the instructions here:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/...
The config file (redacted slightly) is at the bottom.
Most of the time, when I first login to the client system, using credentials from AD, the only group I see is 'domain users'. It's quite slow to login (a couple of minutes). When I interrogate the cache, the user I'm logging in as shows up against many of the groups as 'ghost: username' (I don't know what this means), as well as 'original_member:'.
When I run a simple 'groups username' against other users in the domain, I mostly get just 'domain users', but sometimes (infrequently) it will a list the right set of groups.
Can anyone provide some pointers on what I should be looking at to get the groups showing up reliably?
Thanks,
Robert.
[sssd]
config_file_version = 2
domains = ad.example.com
services = nss, pam, pac
debug_level = 7
[domain/ad.example.com]
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = simple
simple_allow_users = crs, [...others...]
cache_credentials = true
debug_level = 7
[nss]
debug_level = 9
[pam]
[pac]
debug_level = 10
7 years, 8 months
Cross domain trust and SSO/NFS ?
by Joakim Tjernlund
We are migrating to a new domain AD domain and I got cross domain trust problems(there is a bidirectional
cross trust between the two ADs, how can I test this works from Linux?). All users in domain A
has been copied to domain B(using the same UID/GID as in domain A).
I have managed to configure sssd for both domains(lets call the old domain A and the new B),
joined to both domains and I can login using any of the 2 domains.
But here is the problem:
If I use the new domain(B) as default login domain, I cannot ssh to another system still in domain A
password less(without entering my password again) or access files on NFS mounted files exported from domain A.
I know very little about cross trust etc. so I want to ask:
1) Is this even possible?
2) I have no idea where to start looking for what went wrong, need som pointers.
We are using sssd 1.13.4 on the new domain B machines while servers
in domain A uses an older sssd(1.12.5)
Jocke
7 years, 8 months
dyndns updates in sssd-13.4
by Longina Przybyszewska
Hi ,
After upgrade to sssd-13.4, dyndns updates don't work in AD cross realm environment
Our DNS server is :
-not on the identity server (exactly, not on the default DC for the domain)
-DNS server and reverse DNS server are different machines
It worked in previous release (also, DNS updates only)
Now, for fixing this I need to use the option 'dyndns_server' for explicitly point to the server.
It is not possible for dyndns_ptr updates, since sssd obviously assumes that there is one DNS for both A and PTR records.
Do you plan 'dyndns_ptr_server' option as well in future realeseS?
Best,
Longina
7 years, 8 months
SSSD SUDO Groups
by Jagannath Naidu
HI List,
I am able to do the following
Environment:
windows 2012 AD
CentOS 6
1. Authenticate users based on group
2. users are able to sudo
My Question:
Suppose I want to create multiple sudo groups, say two sudo groups.
1. one group has has access to use commands fdisk,chmod
2. Another group has access use su command
Is it possible to differentiate users to restrict sudo access ? Please help
me here to resolve this issue.
Regards
Jagannath Naidu
7 years, 8 months
Re: nfsidmap with 'sss'method[SOLVED]
by Longina Przybyszewska
Hi again,
I tracked down the problem probably to the NFS server's idmapd.conf configuration - which was not identical on both machines:
Nfs-server (sssd-12.5) used Method = nsswitch, while Nfs-client Method = sss;
Nfs-server is configured differently than nfs-client, it has all domains listed explicitly in sssd.conf;
Nfs-client (sssd-13.4) has only one domain (join domain) listed.
This configuration worked up to sssd-13.3 (on client side)
Best
Longina
> -----Original Message-----
> From: Jakub Hrozek [mailto:jhrozek@redhat.com]
> Sent: 28. juli 2016 09:52
> To: sssd-users(a)lists.fedorahosted.org
> Subject: [SSSD-users] Re: nfsidmap with 'sss'method
>
> On Wed, Jul 27, 2016 at 01:46:31PM +0000, Longina Przybyszewska wrote:
> > Hi,
> > I upgraded to sssd-13.4 (kernel 4.4.0-31-generic #50-Ubuntu) -.
> >
> > After upgrade I have problems with nfs4+Kerberos idmaping, using krb
> localauth snippet and choosing 'sss' method in /etc/idmap.conf;
> > I get (igen!) famous nobody mapping for cross realm users; Mapping of
> > groups is correct, as groups are in the same domain as computers.
> >
> > I can mount with sec=krb5, get access to my nfs-mounted home directory,
> get r/w permissions, but listing a file shows wrong owner:
> >
> > ausr@nat.domain@adm-lnx438:~$ ls -ld .
> > drwxr-xr-x 3 4294967294 lnx-primary(a)adm.domain 28 Aug 18 2015 SSSD-
> GIT
> >
> > ausr(a)nat.domain --> 4294967294
> > group(a)adm.domain --> group
> >
> > In logfile:
> > Jul 27 14:23:55 adm-lnx438 nfsidmap[22500]: key: 0x26626a54 type: uid
> > value: ausr@nat.domain(a)adm.domain timeout 600 Jul 27 14:23:55
> > adm-lnx438 nfsidmap[22500]: nfs4_name_to_uid: calling
> > sss_nfs->name_to_uid Jul 27 14:23:55 adm-lnx438 nfsidmap[22500]: user
> > ausr@nat.domain(a)adm.domain not in memcache Jul 27 14:23:56 adm-
> lnx438
> > nfsidmap[22500]: sss_nfs_name_to_uid: rc=2 msg=No such file or
> > directory
>
> It looks like the sss_nfs_* functions are at least called, is there anything in
> the logs around that time?
>
> > Jul 27 14:23:56 adm-lnx438 nfsidmap[22500]: nfs4_name_to_uid:
> > sss_nfs->name_to_uid returned -2 Jul 27 14:23:56 adm-lnx438
> > nfsidmap[22500]: nfs4_name_to_uid: final return value is -2 Jul 27
> > 14:23:56 adm-lnx438 nfsidmap[22500]: nfs4_name_to_uid: calling
> > sss_nfs->name_to_uid Jul 27 14:23:56 adm-lnx438 nfsidmap[22500]: user
> > nobody(a)adm.domain not in memcache Jul 27 14:23:56 adm-lnx438
> > nfsidmap[22500]: sss_nfs_name_to_uid: rc=2 msg=No such file or
> > directory Jul 27 14:23:56 adm-lnx438 nfsidmap[22500]:
> > nfs4_name_to_uid: sss_nfs->name_to_uid returned -2 Jul 27 14:23:56
> > adm-lnx438 nfsidmap[22500]: nfs4_name_to_uid: final return value is -2
> > Jul 27 14:23:56 adm-lnx438 nfsidmap[22504]: key: 0x276b113b type: gid
> > value: lnx-primary(a)adm.domain timeout 600 Jul 27 14:23:56 adm-lnx438
> > nfsidmap[22504]: nfs4_name_to_gid: calling sss_nfs->name_to_gid Jul 27
> > 14:23:56 adm-lnx438 nfsidmap[22504]: found group
> > lnx-primary(a)adm.domain in memcache Jul 27 14:23:56 adm-lnx438
> > nfsidmap[22504]: sss_nfs_name_to_gid: rc=0 msg=Success Jul 27 14:23:56
> > adm-lnx438 nfsidmap[22504]: nfs4_name_to_gid: sss_nfs->name_to_gid
> > returned 0 Jul 27 14:23:56 adm-lnx438 nfsidmap[22504]:
> > nfs4_name_to_gid: final return value is 0
> >
> > ----
> > getent passwd ausr(a)nat.domain
> > ausr@nat.domain:*:10002:30000000:Ausr :/home/ausr:/bin/bash
> >
> > id ausr(a)nat.domain
> > uid=10002(ausr(a)nat.domain) gid=30000000(lnx-primary(a)adm.domain)
> > groups=30000000(lnx-
> primary(a)adm.domain),4(adm),24(cdrom),27(sudo),46(p
> > lugdev),113(lpadmin),131(lxd),),9002(lnx-xxx-nfs4users2(a)c.xxx.dk),6666
> > (nfs4users2(a)nat.domain),30000006(data-adm-lnx-nfs0a-qbl-admin-id-
> 00001
> > @adm.domain),9999(usr-xxx-
> glu@c.xxx.dk),8888(nfs4users(a)nat.domain),300
> > 00002(lnx-ladm-clients(a)adm.domain)
> >
> > Any ideas what could happen?
> >
> > Best
> > Longina
> >
>
> > _______________________________________________
> > sssd-users mailing list
> > sssd-users(a)lists.fedorahosted.org
> > https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahost
> > ed.org
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/admin/lists/sssd-
> users(a)lists.fedorahosted.org
7 years, 8 months
NFSserver sss_nfs_princ_to_ids: not implemented
by Longina Przybyszewska
Hi,
I am testing the new NFS-server with Kerberos ,and interaction with Nfs-client, all based on Ubuntu-16.04 and sssd-13.4.
I have got a systematic "Permission denied" for owner accessing home directory , mounted on Nfs-client, with right permissions and right nfsidmapping.
In the syslog on the Nfs-server I found following messages - coming when resolving machine's principal name , and the file owner's principal name :
rpc.svcgssd[3126]: nfs4_gss_princ_to_ids: calling sss_nfs->princ_to_ids
rpc.svcgssd[3126]: sss_nfs_princ_to_ids: not implemented
The strange thing is, that during login process I can mount homedir with right permissions and the right nfs name mapping !
kernel version for both , NFs-server/client is 4.4.0-31-generic #50 -Ubuntu;
The same Nfs-client mounts home directory from the old server (NFS+Kerberos, sssd-12.5) without problems.
Any idea?
Mange hilsner
Longina
7 years, 8 months
sssd System error
by Schiller Frank
Hi,
I'm trying to authenticate with active-directory users (Windows Server 2008 R2) on my Ubuntu 16.04 workstation.
I used the steps in "SSSD and Active Directory" from the Ubuntu documentation.
Adding the computer-account to active-directory worked.
Running id <active-directory-user> also returns the correct active-directory-groups the user is in.
But I can't login with active-directory-user.
content of /var/log/auth.log:
pam_sss(login:auth): authentication success; logname=LOGIN uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=<active-directory-user>
pam_sss(login:account): Access denied for user<active-directory-user>: 4 (System error)
output of "service sssd status":
sssd.service - System Security Services Daemon
Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
Active: active (running) since Mo 2016-07-25 12:47:37 CEST; 35min ago
Process: 1913 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS) Main PID: 2088 (sssd)
CGroup: /system.slice/sssd.service
├─2088 /usr/sbin/sssd -D -f
├─2092 /usr/lib/x86_64-linux-gnu/sssd/sssd_be --domain DOMAIN.LOCAL --uid 0 --gid 0 --debug-to-files
├─2131 /usr/lib/x86_64-linux-gnu/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files
└─2132 /usr/lib/x86_64-linux-gnu/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files
Jul 25 12:49:21 ubuntu16 sssd_be[2092]: GSSAPI client step 1
Thank you very much for any help.
Best Regards
Frank
7 years, 8 months
