speeding up iterative enumeration?
by James Ralston
We are using the ad provider for sssd, with the id mapping feature
enabled.
We have a program that obtains a list of all Active Directory users and
groups via LDAP, and then calls getpwnam()/getgrnam() on those users
and groups.
(We used to accomplish this enumeration simply by enabling enumeration
within sssd. But the performance issues this created for sssd,
combined with the threat of the removal of the enumeration feature,
made us search for a different solution.)
Here's the problem: unless the user/group objects already happen to be
in sssd's cache, enumerating the passwd/group entries in this way is
very slow: 3-5 entries per second, at best. For a larger AD domain,
the program can take 10-15 minutes to perform this iterative
enumeration, which is much longer than we'd prefer.
Can anyone think of a way to make this iterative enumeration go
faster?
One thing we're considering is having our program synthesize the
passwd and group entries itself, rather than having sssd do it via
getpwnam()/getgrnam() calls. We'll still have to look up at least one
entry (to determine the slice starting point for the ID mapping), but
since we can obtain each object's RID from AD, once we know the
starting offset, we can calculate the uid/gid values. After that, all
we need to do is synthesize the rest of the fields from the object's
AD properties, the same as sssd.
Thoughts? Is there a way to accelerate iterative enumeration, or
should we just give up and replicate the logic sssd uses to generate
passwd/group entries?
8 years, 2 months
Help debugging sssd-sudo with Samba4
by Juan Asensio Sánchez
Hi
I an trying to get sudo with sssd work with Samba4 provider, but I can't. I
have joined the domain using realmd:
realm --client-software=sssd join mmdd.indra.es
After that, I have modified some sssd settings, to add sudo service, enable
enumerate (during debigging), etc.:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[sssd]
domains = xxxx.yyyy.es
config_file_version = 2
services = nss, pam, sudo, ssh
[sudo]
[ssh]
[domain/xxxx.yyyy.es]
enumerate = True
ad_domain = xxxx.yyyy.es
krb5_realm = XXXX.YYYY.ES
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
use_fully_qualified_names = False
fallback_homedir = /home/%u
access_provider = ad
case_sensitive = false
ldap_user_ssh_public_key = sshPublicKey
sudo_provider = ldap
ldap_sudo_search_base = OU=SUDOers,DC=xxxx,DC=yyyy,DC=es
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enabled and restarted sssd, oddjob. Now I see users and group using getent,
and I can login to the client using SSH.
Then, added to Samba4 the OU=SUDOers tree:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dn: OU=SUDOers,DC=xxxx,DC=yyyy,DC=es
objectClass: organizationalUnit
objectClass: top
ou: SUDOers
name: SUDOers
dn: CN=wheel,OU=SUDOers,DC=xxxx,DC=yyyy,DC=es
objectClass: sudoRole
objectClass: top
cn: wheel
name: wheel
sudoCommand: ALL
sudoHost: ALL
sudoUser: %wheel
dn: CN=root,OU=SUDOers,DC=xxxx,DC=yyyy,DC=es
objectClass: sudoRole
objectClass: top
cn: root
name: root
sudoCommand: ALL
sudoHost: ALL
sudoUser: root
dn: CN=sysadm,OU=SUDOers,DC=xxxx,DC=yyyy,DC=es
objectClass: sudoRole
objectClass: top
cn: sysadm
name: sysadm
sudoCommand: ALL
sudoHost: ALL
sudoUser: %sysadm
dn: CN=defaults,OU=SUDOers,DC=xxxx,DC=yyyy,DC=es
objectClass: sudoRole
objectClass: top
cn: defaults
description: Default sudoOptions go here
distinguishedName: CN=defaults,OU=SUDOers,DC=xxxx,DC=yyyy,DC=es
name: defaults
sudoOption: env_keep+=SSH_AUTH_SOCK
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I have a user that is member of the sysadm group (I show only relevant
information):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dn: CN=My Full Name,OU=Usuarios,DC=xxxx,DC=yyyy,DC=es
objectClass: posixAccount
sAMAccountName: jasensios
gidNumber: 10004
loginShell: /bin/bash
memberOf: CN=sysadm,OU=Grupos,DC=mmdd,DC=indra,DC=es
msSFU30Name: jasensios
msSFU30NisDomain: xxxx
msSFU30PosixMemberOf: CN=sysadm,OU=Grupos,DC=xxxx,DC=yyyy,DC=es
uid: jasensios
uidNumber: 10000
unixHomeDirectory: /home/jasensios
dn: CN=sysadm,OU=Grupos,DC=xxxx,DC=yyyy,DC=es
objectClass: posixGroup
cn: sysadm
sAMAccountName: sysadm
gidNumber: 10014
member:
memberUid: jasensios
msSFU30Name: sysadm
msSFU30NisDomain: xxxx
msSFU30PosixMember: CN=My Full Name,OU=Usuarios,DC=xxxx,DC=yyyy,DC=es
name: sysadm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After loging with user in the client:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[jasensios@client01 ~]$ id
uid=10000(jasensios) gid=10004(domain users) grupos=10004(domain
users),10005(sysadm_pro),10014(sysadm)
[jasensios@client01 ~]$ groups
domain users sysadm
[jasensios@client01 ~]$ getent passwd jasensios
jasensios:*:10000:10004:My Full Name:/home/jasensios:/bin/bash
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
But....
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[jasensios@client01 ~]$ sudo -l
[sudo] password for jasensios:
User jasensios is not allowed to run sudo on client01.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Any advice?
8 years, 2 months
SSSD issue after upgrade in fedora 23 x64
by Edouard Guigné
Hello sssd users,
I configured several fedora 22 x64 workstation with success with sssd against a AD domain.
I followed the tutorial at https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server ("Joining the Linux client to the AD domain manually" part).
Last week, I upgrraded my workstation from fedora 22 to fedora 23 x64 (using fedup).
I did not change the sssd.conf, krb5.conf and krb5.keytab from fedora 22 to 23.
In all upgraded fedora 23 workstations, users cannot loging anymore. Here is the error i get :
sshd[9313]: pam_sss(sshd:account): Access denied for user xxxxx: 4 (System error)
sshd[9313]: Failed password for xxxxx from x.x.x.x port 49459 ssh2
audit[9313]: USER_ACCT pid=9313 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=? acct="xxxxx" exe="/usr/sbin/sshd" hostname=x.x.x.x addr=x.x.x.x terminal=ssh res=failed'
sshd[9313]: fatal: Access denied for user xxxxx by PAM account configuration [preauth]
...
Although, users can still loging in fedora 22 workstations.
Is it a known issue ? May you help me to resolve it ?
Best Regards,
Ed
8 years, 2 months
User_attribute option
by Longina Przybyszewska
Hi,
I would like to retrieve additional attribute from user object in AD , 'homeDirectory', which contains string pointing to
windows share path on a samba server .
The option 'user_attribute' allows that setup in [nss] section together with ' ifp' service.
[sssd]
services = ..,nss,ifp
[nss]
user_attribute = +homeDirectory
I can't figure out how this extra attribute is mapped by SSSD;
I would like map it to environment variable per user at login, or in any other usable way.
Any hints?
Thanks in advance.
Best,
longina
8 years, 2 months
Only members of one AD group should have access to Linux login
by Hans Schou
Hi
I have several users in my AD. All of them can now login with ssh to the Linux server which is not intended.
In the AD I have the group MyTestGrp. I want only users in that group to have access to this server.
Testing on the Linux server provides the information necessary ("admjoin" should not have access):
avgjoe@host007:~$ getent passwd admjoin
admjoin:*:1905540256:1905400513:AdmJoin:/home/corp.acme.com/admjoin:/bin/...
avgjoe@host007:~$ getent group MyTestGrp
MyTestGrp:*:1905738908:avgjoe,bob
Where should I add MyTestGrp in the configuration files?
I have looked around in /etc/sssd/ and /etc/pam.d/ without success.
It is working now with sudo for the group members so I guess it should be possible.
best regards
8 years, 2 months
sssd net rpc rights SeDiskOperatorPrivilege
by Henry McLaughlin
I have sssd configured and working with my domain member server and I now wish to grant the SeDiskOperatorPrivilege to the "MYDOMAIN\Domain Admins" group. When I execute the command it appears to disregard the domain name and grant the privileges to the group "Unix Group\domain admins"
net rpc rights list accounts -U'MYDOMAIN\administrator'
Enter MYDOMAIN\administrator's password:
...
Unix Group\domain admins
No privileges assigned
net rpc rights grant 'MYDOMAIN\Domain Admins' SeDiskOperatorPrivilege -U'MYDOMAIN\administrator'
Enter MYDOMAIN\administrator's password:
Successfully granted rights.
net rpc rights list accounts -U'MYDOMAIN\administrator'
Enter MYDOMAIN\administrator's password:
...
Unix Group\domain admins
SeDiskOperatorPrivilege
net rpc rights revoke 'MYDOMAIN\Domain Admins' SeDiskOperatorPrivilege -U'MYDOMAIN\administrator'
Enter MYDOMAIN\administrator's password:
Successfully revoked rights.
net rpc rights list accounts -U'MYDOMAIN\administrator'
Enter MYDOMAIN\administrator's password:
...
Unix Group\domain admins
No privileges assigned
Below I have completely removed the domain name from the command and still get the same outcome.
net rpc rights grant 'Domain Admins' SeDiskOperatorPrivilege -U'MYDOMAIN\administrator'
Enter MYDOMAIN\administrator's password:
Successfully granted rights.
net rpc rights list accounts -U'MYDOMAIN\administrator'
Enter MYDOMAIN\administrator's password:
...
Unix Group\domain admins
SeDiskOperatorPrivilege
8 years, 2 months
Could not convert objectSID [...] to a UNIX ID
by Hans Schou
Hi
I have two users in the AD. Only one of them can login with ssh or su on the Linux server.
The user admjoin is the one made the "realm join" and he can login:
/var/log/sssd/sssd_corp.acme.com.log:
Mapping user [AdmJoin] objectSID [S-1-5-21-2031436270-1094658265-1854952973-140256] to unix ID
Adding original memberOf attributes to [AdmJoin].
And avgjoe can not login:
Mapping user [AvgJoe] objectSID [S-1-5-21-2031436270-1094658265-1854952973-340002] to unix ID
Could not convert objectSID [S-1-5-21-2031436270-1094658265-1854952973-340002] to a UNIX ID
Why can user avgjoe not log in?
(and why are the ObjectSID the same (if relevant)?)
Note that when doing a "su - avgjoe" the AD converts it to AvgJoe in log-file, as defined on the AD-server.
I guess there is around 20000 users defined in the AD. User AdmJoin was created when the system was setup, and user AvgJoe is added recently (he might have a very high numeric id).
[sssd]
domains = corp.acme.com
config_file_version = 2
services = nss, pam, ssh, sudo
debug_level = 7
[domain/corp.acme.com]
ad_domain = corp.acme.com
krb5_realm = CORP.ACME.COM
realmd_tags = manages-system joined-with-samba
#cache_credentials = True
cache_credentials = False
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%d/%u
access_provider = ad
debug_level = 7
ldap_idmap_range_min = 200000
ldap_idmap_range_max = 2000200000
ldap_idmap_range_size = 200000
Any help is much appreciated.
best regards
Hans
8 years, 2 months
Re: localauth plugin and some other questions (+ attch.)
by Longina Przybyszewska
This time with attachments ;-)
HI,
Sorry for delay...
In attachements sssd_nss.log and sssd_a.c.realm.log
Login with UPN (mail name) does not work here:
root@adm-lnx438:/tmp# getent passwd user1@realm
user1@n.c.realm@a.c.realm:*:10002:30000000:XXXXX XXXXX:/home/user1:/bin/bash
my sssd.conf:
[nss]
debug_level = 9
filter_groups = root
filter_users = root
[sssd]
debug_level = 9
domains = a.c.realm
config_file_version = 2
services = nss,pam,ssh
[pam]
pam_verbosity = 3
debug_level = 9
[domain/a.c.realm]
debug_level = 9
ad_domain = a.c.realm
ad_site = SITE
ad_hostname = adm-lnx438.a.c.realm
id_provider = ad
access_provider = ad
auth_provider = ad
chpass_provider = ad
dyndns_update = true
dyndns_update_ptr = false
krb5_realm = A.C.REALM
krb5_use_fast = try
krb5_lifetime = 10h
krb5_renewable_lifetime = 7d
krb5_renew_interval = 1h
krb5_confd_path = /var/lib/sss/pubconf/krb5.include.d
###
use_fully_qualified_names = true
ldap_id_mapping = false
ldap_use_tokengroup = false
ad_gpo_access_control = disabled
best,
Longina
> -----Oprindelig meddelelse-----
> Fra: Longina Przybyszewska [mailto:longina@sdu.dk]
> Sendt: 11. januar 2016 16:25
> Til: End-user discussions about the System Security Services Daemon
> Emne: [SSSD-users] Re: localauth plugin and some other questions
>
>
>
> > -----Oprindelig meddelelse-----
> > Fra: Sumit Bose [mailto:sbose@redhat.com]
> > Sendt: 8. januar 2016 11:23
> > Til: End-user discussions about the System Security Services Daemon
> > Emne: [SSSD-users] Re: localauth plugin and some other questions
> >
> > On Wed, Jan 06, 2016 at 01:11:50PM +0000, Longina Przybyszewska wrote:
> > >
> > > Thank you for the answers.
> > > There are still some issues:
> > >
> > >
> > > > > 2.
> > > > > I tried login with setup for UPN/sAMAccountName login- without
> > success.
> > > > > Is login with cross realm's UPN or short sAMAccoutName supported
> in
> > this
> > > > sssd version?
> > > > >
> > > > > In database for default domain cache_a.c.realm.db user object
> > > > > has
> > > > following names (for 'use_fully_qualified_names = true' setup):
> > > > >
> > > > > dn: name = user1(a)n.c.realm ...
> > > > > name: user1(a)n.c.realm
> > > > > nameAlias. user1(a)n.c.realm
> > > > > UserPrincipalName: user1@REALM
> > > > > canonicalUserPrincipalName: user1(a)N.C.REALM
> > > >
> > > > The plain sAMAccoutName 'user1' will not work because
> > > > use_fully_qualified_names = true. What should work is 'DOM\user1'
> > > > where DOM is the NetBIOS domain name of n.c.realm domain.
> > > > Additionally I would expect that user1@REALM should work.
> > > >
> > >
> > > Right. user1(a)n.c.realm and DOM\user1 login works.
> > >
> > > Login as user1@REALM (and user1@realm) does not work.
> >
> > hm, that's odd, can you send me the logs when trying to login with
> > user1@REALM?
> >
> > >
> > > getent passwd user1@realm
> > > user1@n.c.realm@a.c.realm:*:10002:30000000::/home/user1:/bin/bash
> >
> > 'user1@n.c.realm(a)a.c.realm' looks odd, do you map the user name to an
> > attribute other than sAMAccoutName?
> >
>
> I use " id_provider = ad" and do not map specifically user name to any
> attribute..
>
> Attributes in AD:
> uid = user1
> userPrincipalName = user1@realm
> sAMAccountName = user1
>
> SSSD defaults:
> ldap_user_name = uid
> ldap_user_principal = krbPrincipalName
>
> krb5_use_enterprise_principal = true
>
> There is no krbPrincipalName attribute in user object in AD .
>
> Sssd.conf:
>
>
> [nss]
> debug_level = 9
> filter_groups = root
> filter_users = root
>
> [sssd]
> debug_level = 9
>
> domains = a.c.realm
> config_file_version = 2
> services = nss, pam,ssh
>
> [pam]
> pam_verbosity = 3
> debug_level = 9
>
> [domain/a.c.realm]
> debug_level = 9
>
> ldap_use_tokengroup = false
> dyndns_update = true
> dyndns_update_ptr = true
>
> id_provider = ad
> access_provider = ad
> auth_provider = ad
> chpass_provider = ad
>
> krb5_realm = A.C.REALM
> krb5_use_fast = try
> krb5_confd_path = /var/lib/sss/pubconf/krb5.include.d
>
> ad_domain = a.c.realm
> ad_site = SITE
> ad_hostname = adm-lnx438.a.c.realm
>
> use_fully_qualified_names = true
> ldap_id_mapping = false
>
>
>
> > >
> > > The best would be able to login with sAMAccountName; The next best
> > > with upn, then with fqdn.
> > >
> > > I tried without success the following setup for login with short names :
> > > [nss]
> > > subdomain_inherit = ldap_user_principal
> > >
> > > [domain/a.c.realm]
> > > ..
> > > ldap_user_principal = sAMAccountName
> >
> > this won't work because ldap_user_principal value is used as a
> > Kerberos principal without further processing.
> >
> > You might want to try the 'default_domain_suffix' option, see man
> > sssd.conf for details.
> >
> Manual says, that 'default_domain_suffix' is usable if all users are located in
> trusted domain while computer's are in primary domain.
> With this option, users can login with short names.
> Our users are in several trusted domains; what should be the value of
> 'default_domain_suffix' ?
>
> > >
> > >
8 years, 2 months
localauth plugin and some other questions
by Longina Przybyszewska
Hi,
I did some testing of sssd-13.2 version in Ubuntu-16.04 (ldap_idmapping = false)
Login with fqdn in cross realm and Kerberos NFS automount seems to work almost out-of-the-box.
This is great.
I have still some questions:
In my setup, I have configured only for one domain - the domain where I join machine.
SRV discovery can figure out all domains and figure out AD structure;
1.
Is it still necessary make an explicit list of all domains in the 'domains' statement?
[sssd]
..
domains = a.c.realm, n.c.realm, s.c.realm, c.realm ...
2.
I tried login with setup for UPN/sAMAccountName login- without success.
Is login with cross realm's UPN or short sAMAccoutName supported in this sssd version?
In database for default domain cache_a.c.realm.db user object has following names (for 'use_fully_qualified_names = true' setup):
dn: name = user1(a)n.c.realm ...
name: user1(a)n.c.realm
nameAlias. user1(a)n.c.realm
UserPrincipalName: user1@REALM
canonicalUserPrincipalName: user1(a)N.C.REALM
3.
Localauth plugin:
the option :
krb5_confd_path = /var/lib/sss/pubconf/krb5.conf.d
-does not create that directory (I understand from the doc that sssd should take care about it);
However after manually creating this directory I can see many fails in log:
[sssd[be[a.c.realm]]] [sss_write_domain_mappings] (0x0200): Mapping file for domain [a.c.realm] is [/var/lib/sss/pubconf/krb5.include.d/domain_realm_a_c_realm]
[sssd[be[a.c.realm]]] [sss_write_domain_mappings] (0x0040): creating the temp file [/var/lib/sss/pubconf/krb5.include.d/domain_realm_a_c_realmU4PYcJ] for domain-realm mappings failed.
[sssd[be[a.c.realm]]] [sss_write_domain_mappings] (0x0080): Could not remove file [/var/lib/sss/pubconf/krb5.include.d/domain_realm_a_c_realmU4P<B0>]: [2]: No such file or directory
....
ls -ld
drwxr-xr-x 2 root root 4096 Dec 16 16:08 /var/lib/sss/pubconf/krb5.conf.d/
Default value for option 'krb5_canonicalize' is FALSE;
I set 'canonicalize' to 'true' in krb5.conf - is it enough? I understand from docs localauth plugin needs it.
4.
ldbsearch
Can I somehow (I do not think about log with high debug level) see all configured and default options for SSSD?
Best,
Longina
8 years, 2 months
Disabling SSSD Discovery Service
by Eric Aiken
I’ve been beating my head over this. After upgrading RHEL5 systems to RHEL6, the kerberos/ldap services quit working correctly. I’ve resolved most of the issues. I also embraced SSSD.
My remaining challenge is to disable the SSSD Discovery service. Authentication and authorization works, it’s just DNS round-robins DC’s that are not reachable and this ultimately causes failures (and latency)
In short I need to hard code who the client talks to. Inevitably I keep finding the client doing a DNS lookup for domaindnszones.<domain>. Due to limitations in MS windows DNS, This returns IP’s for DC’s in VLANs not accessible to certain subnets. Round-Robin DNS with subnet masking doesn’t work for clients that are not AD CSE capable. (eg AD client side extension). Even if I could get the net masking to work, I don’t believe it would work for our IP space as the necessary netmask would need to be a class A , thereby getting all the DC’s again.
For the record AD (and our IP subnets) are configured properly for sites and services.
I’ve tried lots of variations and configurations of:
hardcoding:
kdc =
admin_server =
krb5_backup-server =
dns_lookup_realm = false
dns_lookup_dc = false
ldap_uri
ldap_backup_uri
I tried working with sssd-ad as it allows you to define ad_server and ad_enable_dns_sites. Again the sssd discovery service continues to try and “control” where to look.
From my research I’m not alone, there are others with similar challenges, but I’ve yet to find someone with an “old-school” configuration.
Is there a way to tell sssd use “ these and only these” DC’s for Kerberos and LDAP on a client? I’ll manage HA and load balancing.
Thanks for your thought and advise.
• Respectons ensemble l'environnement. N'imprimez ce message que si nécessaire. Let's respect the environment together. Only print this message if necessary.
8 years, 2 months