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
Re: [SSSD-users] sssd-ldap caching issue ?
by John Beranek
For what it's worth, in my environment at work, I am *not* able to
reproduce this. Ran the test on a RHEL 6.7 Beta (sssd-1.12.4-31.el6.x86_64)
VM, with SSSD configured for our corporate Active Directory.
Cheers,
John
8 years, 5 months
sssd and dovecot pam
by Günther J. Niederwimmer
Hello,
I am new with sssd and Linux but I mean it is possible ;-)
I have a centos system created with IPA authentication.
My problem is dovecot in the moment?
is it possible to adapt the Dovecot file for PAM to use sssd
The origin file have this in /etc/pam.d/dovecot
#%PAM-1.0
auth required pam_nologin.so
auth include password-auth
account include password-auth
session include password-auth
I missing sssd and hope afterward I have a correct authentication.
can any please help for this Problem.
I know some is missing for this, "NSS authentication" but this is to high for
me.
Thanks for a answer,
--
mit freundlichen Grüssen / best regards,
Günther J. Niederwimmer
8 years, 6 months
1.12.x Build for Ubuntu 14.04
by Matt .
Hi All,
I have understood that the 1.12.x version will be uploaded very soon
for Ubuntu, but I would like to compile the package at the moment for
some testing.
I ahve issues with building as it cannot find my sources.
I have Git cloned:
http://anonscm.debian.org/cgit/pkg-sssd/sssd.git/tree/?h=master-next
Did a:
dpkg -b . in the sssd folder and after it:
apt-get deb-build sssd
This gives me:
apt-get build-dep sssd
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to find a source package for sssd
Does anyone have some proper instructions to build the 1.12.x package ?
Thanks!
Matt
8 years, 6 months
sssd & dovecot Problem
by Günther J. Niederwimmer
Hello,
I like to run on a centos 7.1 IPA client and dovecot, but it is not possible
for me, to configure this correct.
getent passwd xxx is working, id xxxx is also working.
I can't correct authenticate my user ?
Have any a running system with sssd and help me to find the correct way.
Thanks for a answer
--
mit freundlichen Grüssen / best regards,
Günther J. Niederwimmer
8 years, 6 months
sssd-ldap caching issue ?
by Thomas Hummel
Hello,
I'm using sssd-ldap-1.11.6 (from the official CentOS repo) on CentOS release
6.6 (Final) on a cluster of compute nodes running the slurm scheduler
(http://slurm.schedmd.com/) in 14.11 version.
Sssd is configured without enumerate, with cache_credential and default various
cache timeout values.
It works fine except in the following case where there seem to be a caching
issue :
[ the following is 100% reproducible ]
a) I clear the cache with the following commands :
. /etc/init.d/sssd stop
. rm -rf /var/lib/sss/mc/* /var/lib/sss/db/*
. /etc/init.d/sssd start
b) I launch a "job array" consisting of 100 or so simple task. Basically this
will execute in batch many instances (each one called a task) of the same
program in parallel on the compute node.
Such a job write its output in a .out text file owned by <user>:<gid>.
-> so many processes end up querying sssd in parallel to retrieve the user groups
What happens is that :
. the first task completes without error
. tasks 2 and 3 (or something like that) fail with a "permission denied" message
. tasks > 3 complete without error
. also if we ask slurm to launch each task one after the other instead of in
a parallel fashion, the pb does not occur
Note :
- the job array is very fast since each task is very simple. Many tasks can be
completed under a second of time.
- if I don't clear sssd cache or if I just issue sss_cache -E or -g, the
problem occurs randomly and may be hard to reproduce.
At full debug level, sssd shows ldap answer correcty and sssd, only for entries
not already in cache, is adding so called "fake groups" :
ex : 'Adding fake group gensoft to sysdb'
A simple patch to slurm in order to print (with getgroups(2)) the number of
group of user shows that, for failed tasks, the number of groups retrieved for <user>
is incomplete, which explains the "permission denied" message.
In fact, the missing groups seem to be the "fake" groups which seem to be first
put in sssd cache by the first task.
So my guess is that :
. task 1 fetches groups missing from cache and first flag them as "fake"
. before task1 finishes "resolving" fake groups entry, tasks 2 and 3 discard
those incomplete entries
. task 1 finishes replacing fake by real groups
. following tasks behave as expected regarding groups
Any ideas ?
Thanks
Here is my sssd.conf file :
[sssd]
config_file_version = 2
services = nss, pam
domains = pasteur_ldap_home
[nss]
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
[pam]
[domain/pasteur_ldap_home]
ldap_tls_reqcert = allow
auth_provider = ldap
ldap_schema = rfc2307
ldap_search_base = xxxx
ldap_group_search_base = xxxx
id_provider = ldap
ldap_id_use_start_tls = True
# We do not authorize password change
chpass_provider = none
ldap_uri = ldap://xxxx/
cache_credentials = True
ldap_tls_cacertdir = /etc/openldap/certs
ldap_network_timeout = 3
# getent passwd will only list /etc/passwd, but id or getent passwd login will query ldap
#enumerate = True
ldap_page_size = 500
#debug_level = 0x02F0
debug_level = 0x77F0
--
Thomas Hummel | Institut Pasteur
<hummel(a)pasteur.fr> | Groupe Exploitation et Infrastructure
8 years, 7 months
Authenticating against Samba4 local DC
by Jonathan Hunter
Hi,
I am in the process of setting up sssd for the first time, so
apologies for any simple questions - but I have not been able to find
the answer in the archives, docs or elsewhere.
I have two Samba4 Active Directory domain controllers on this site,
and would like to configure sssd on each of them for local
authentication of users (Samba doesn't support this yet - UID and GID
mappings are inconsistent if using samba winbindd this way)
I believe I have sssd configured at a basic level, but am getting a
strange error.
Both machines are CentOS 6.6 with sssd-*-1.11.6-30.el6_6.4 packages,
Samba 4.2.1 built from source. My (sanitised) sssd.conf is as follows:
[sssd]
config_file_version = 2
domains = domain.tld
services = nss, pam
[domain/domain.tld]
# Once sure everything working OK, change line below to false
enumerate = true
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
ldap_id_mapping = True
ldap_schema = ad
default_shell = /bin/bash
fallback_homedir = /home/%d/%u
Samba4 works just fine on the machine, and indeed using samba's built
in winbindd does work also (but no consistent uid/gid mapping between
machines, hence I am trying to configure sssd)
I am starting sssd with "-i -d 0x03F0" flags to get debug information,
and from the logs things seem fine up to the following point:
[resolv_getsrv_send] (0x0100): Trying to resolve SRV record of
'_ldap._tcp.domain.tld'
but then the execution after this looks like it only works 50% of the time, when
the above line happens to resolve to the *other* DC (i.e. not the
machine I am running sssd on).
I have been testing sssd on one server ("DC1") first of all. When the
above DNS query, which I presume is a round-robin type query,
resolves to DC1 i.e. the local machine, I get:
[be_resolve_server_process] (0x0200): Found address for server
dc1.domain.tld: [1.2.3.4] TTL 900
[ldap_child_get_tgt_sync] (0x0100): Principal name is: [DC1$(a)DOMAIN.TLD]
[...]
[sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: DC1$
[sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error]
[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)]
[fo_set_port_status] (0x0100): Marking port 389 of server
'dc1.domain.tld' as 'not working'
However, it's perfectly happy whenever this DNS query resolves to DC2:
[be_resolve_server_process] (0x0200): Found address for server
dc2.domain.tld: [1.2.3.5] TTL 900
[ldap_child_get_tgt_sync] (0x0100): Principal name is: [DC1$(a)DOMAIN.TLD]
[...]
[sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: DC1$
[child_sig_handler] (0x0100): child [8505] finished successfully.
[fo_set_port_status] (0x0100): Marking port 389 of server
'dc2.domain.tld' as 'working'
[set_server_common_status] (0x0100): Marking server 'dc2.domain.tld'
as 'working'
At first I thought it was something to do with the keytab file (which
is a bit of a black box to me and which I don't quite understand). It
looks to me as though samba4 has a keytab file containing entries for
all users including DC1 and DC2; but I even extracted the keytab for
just DC1 and told sssd to use it directly, which made no difference.
I'm confused as to why DC1 would have a problem authenticating against
itself, whereas DC2 is quite happy for it to do so, using the very
same keytab file.
To test this theory I used:
# samba-tool domain exportkeytab /etc/krb5-dc1.keytab --principal-DC1\$
and added to sssd.conf:
krb5_keytab=/etc/krb5-dc1.keytab
but it made no difference when compared to using the 'full' keytab
file as I had originally.
I've also cleared cache via "# rm -f /var/lib/sss/db/* /var/lib/sss/mc/*".
Can anyone point me in the right direction? I imagine this works for
someone else; but as I've never had sssd configured I'm not sure where
to look next.
Thanks,
Jonathan
--
"If we knew what it was we were doing, it would not be called
research, would it?"
- Albert Einstein
8 years, 7 months
RHEL 6.7 Beta sssd issue
by John Beranek
Hi all,
I've just built a RHEL 6.7 Beta VM to test the new SSSD release, and have
come across a strange issue.
I can successfully kinit and join our AD domain with "net ads join -k" but
sssd won't start. The logs contain:
[ad_set_ad_id_options] (0x0100): Option krb5_realm set to EXAMPLE.COM
[sdap_set_sasl_options] (0x0100): Will look for
rhel67.example.com(a)EXAMPLE.COM in default keytab
[select_principal_from_keytab] (0x0200): trying to select the most
appropriate principal from keytab
[find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed.
[find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed.
[find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed.
[find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed.
[find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed.
[find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed.
[find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed.
[select_principal_from_keytab] (0x0080): No suitable principal found in
keytab
[select_principal_from_keytab] (0x0010): Failed to read keytab [default]:
No such file or directory
[ad_set_ad_id_options] (0x0040): Cannot set the SASL-related options
[load_backend_module] (0x0010): Error (2) in module (ad) initialization
(sssm_ad_id_init)!
[be_process_init] (0x0010): fatal error initializing data providers
Had a little feedback from Lukas, who suggested I ran "klist -kt". This
gives:
# klist -kt
Keytab name: FILE:/etc/krb5.keytab
klist: No such file or directory while starting keytab scan
Any ideas?
John
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
8 years, 7 months
"could not store group" failures for lookups on Active Directory groups
by James Ralston
Hi,
I think this problem may be part (or related to) the "FreeIPA/SSSD
LDAP cross-forest trust slow queries" issue, but I'm not sure.
We've been testing sssd on our RHEL6 and RHEL7 hosts, using the latest
available packages. We have a fairly simple sssd configuration. We
use the "ad" provider with LDAP id mapping:
[sssd]
config_file_version = 2
debug_level = 0x0070
domains = example.org
services = nss, pam
[nss]
debug_level = 0x0070
default_shell = /bin/bash
fallback_homedir = /home/%u
[pam]
debug_level = 0x0070
[domain/example.org]
access_provider = ad
auth_provider = ad
cache_credentials = true
chpass_provider = ad
debug_level = 0x0010
dyndns_update = false
enumerate = true
id_provider = ad
krb5_realm = EXAMPLE.ORG
ldap_id_mapping = true
ldap_sasl_mech = GSSAPI
ldap_schema = AD
offline_failed_login_attempts = 3
Although we have about 1200 groups in Active Directory, only about 900
of them show up in the output of "getent -s sss group". For the
remaining ones, attempting a lookup (e.g., with getent) returns no
entry, and we see these lines in the sssd_example.org.log file:
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]]
[sdap_get_groups_next_base] (0x0400): Searching for groups with base
[DC=example,DC=org]
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]]
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
[(&(name=my-group)(objectClass=group)(name=*))][DC=example,DC=org].
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]] [sdap_parse_entry]
(0x1000): OriginalDN: [CN=my-group,OU=Distribution Groups,OU=Microsoft
Exchange,DC=example,DC=org].
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]]
[sdap_nested_group_hash_group] (0x4000): AD group has type flags 0x8.
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]]
[sdap_nested_group_hash_group] (0x0400): Filtering AD group.
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]]
[sdap_nested_group_hash_group] (0x4000): The group's gid was zero
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]]
[sdap_nested_group_hash_group] (0x2000): Marking group as non-posix
and setting GID=0!
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]]
[sdap_nested_group_hash_entry] (0x4000): Inserting
[CN=my-group,OU=Distribution Groups,OU=Microsoft
Exchange,DC=example,DC=org] into hash table [groups]
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]]
[sdap_nested_group_process_send] (0x2000): About to process group
[CN=my-group,OU=Distribution Groups,OU=Microsoft
Exchange,DC=example,DC=org]
[user lookups omitted]
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]]
[sdap_get_primary_name] (0x0400): Processing object my-group
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]] [sdap_save_group]
(0x0400): Processing group my-group
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]] [sdap_save_group]
(0x4000): AD group [my-group] has type flags 0x8.
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]] [sdap_save_group]
(0x0400): Filtering AD group [my-group].
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]]
[sdap_attrs_add_ldap_attr] (0x2000): Adding original DN
[CN=my-group,OU=Distribution Groups,OU=Microsoft
Exchange,DC=example,DC=org] to attributes of [my-group].
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]]
[sdap_attrs_add_ldap_attr] (0x2000): Adding original mod-Timestamp
[20150429215241.0Z] to attributes of [my-group].
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]]
[sdap_process_ghost_members] (0x0400): The group has 5 members
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]]
[sdap_process_ghost_members] (0x0400): Group has 5 members
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]]
[sysdb_attrs_get_aliases] (0x2000): Domain is case-insensitive; will
add lowercased aliases
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]] [sdap_save_group]
(0x0400): Storing info for group my-group
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]]
[sysdb_set_entry_attr] (0x0080): ldb_modify failed: [Attribute or
value exists]
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]]
[sysdb_set_entry_attr] (0x0040): Error: 17 (File exists)
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]] [sysdb_store_group]
(0x1000): sysdb_set_group_attr failed.
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]] [sysdb_store_group]
(0x0400): Error: 17 (File exists)
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]]
[sdap_store_group_with_gid] (0x0040): Could not store group my-group
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]] [sdap_save_group]
(0x0080): Could not store group with GID: [File exists]
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]] [sdap_save_group]
(0x0080): Failed to save group [my-group]: [File exists]
(Wed May 6 00:03:06 2015) [sssd[be[example.org]]] [sdap_save_groups]
(0x0040): Failed to store group 0. Ignoring.
I can't find any pattern for what groups are correctly mapped versus
the groups that aren't. But it's consistent across different sssd
client hosts. Stopping sssd and removing its cache has no effect.
Nor does disabling enumeration.
Since we just recently started testing sssd, we don't know for certain
whether group lookups worked properly in the past. All we know is
that it doesn't seem to work now.
Is this a known issue, or is this a new problem I should report to
Bugzilla and/or Red Hat support?
If the former, is a patch available? Because if so, I'll rebuild our
sssd RPMs locally with the patch until Red Hat releases official
updated packages...
Thanks in advance for any assistance anyone might have...
8 years, 7 months