I am on sssd 1.11.6
I seem to have gotten it to partially work at least for login. I mapped the gid attribute
to something else and it worked for ssh login. It seems if I set the uid and gid to the
same attribute it fails with :
(Thu Nov 13 10:12:10 2014) [sssd[be[LDAP]]] [sdap_save_user] (0x0020): no gid provided for
[xxxx] in domain [LDAP].
(Thu Nov 13 10:12:10 2014) [sssd[be[LDAP]]] [sdap_save_user] (0x0020): Failed to save user
[xxxx]
It also seems I have to have the local group created since our LDAP does not use groups at
all.
Is there a way I could create a local unix group, say “users” with local gid like 5000 and
then have all users that login via ldap mapped to that group without having that gid in
LDAP
What’s happening is my ssh user can log in with ldap credentials, but it doesn’t create a
home directory.
N
On Nov 13, 2014, at 10:01 AM, Jakub Hrozek <jhrozek(a)redhat.com> wrote:
On Thu, Nov 13, 2014 at 03:29:32PM +0000, Nathan Robbins wrote:
> sssd.conf:
>
> [domain/LDAP]
> enumerate = False
> cache_credentials = False
> id_provider = ldap
> auth_provider = ldap
> ldap_uri = ldap://server:port
> ldap_id_use_start_tls = True
> ldap_tls_reqcert = allow
> ldap_tls_cacertdir = /etc/openldap/cacerts
> ldap_search_base = ou=People,dc=xxxx,dc=xxxx,c=us
> ldap_default_bind_dn = uid=xxx,ou=xx,dc=xxx,dc=xxx,c=us
> ldap_schema = rfc2307
> ldap_default_authtok_type = password
> ldap_default_authtok = xxxx
> ldap_user_object_class = inetOrgPerson
> ldap_search_timeout = 60
> ldap_network_timeout = 60
> debug_level = 4
> min_id = 0
>
> ldap_user_uid_number = employeeNumber
> ldap_user_gid_number = employeeNumber
> ldap_user_gecos = cn
Thanks, this should work. Can you send the (sanitized) sssd domain logs?
Which sssd version is this?
>
> [sssd]
> services = nss, pam
> config_file_version = 2
> domains = LDAP
>
> [nss]
> homedir_substring = /home
>
> [pam]
>
> [sudo]
>
> [autofs]
>
> [ssh]
>
> [pac]
>
> [ifp]
>
>
> On Nov 13, 2014, at 9:20 AM, Nathan Robbins
<nrobbins@olemiss.edu<mailto:nrobbins@olemiss.edu>> wrote:
>
> I have enumerate = False
>
> I will post sssd.conf shortly when I return to the office shortly.
>
> ----- Reply message -----
> From: "Jakub Hrozek"
<jhrozek@redhat.com<mailto:jhrozek@redhat.com>>
> To:
"sssd-devel@lists.fedorahosted.org<mailto:sssd-devel@lists.fedorahosted.org>"
<sssd-devel@lists.fedorahosted.org<mailto:sssd-devel@lists.fedorahosted.org>>
> Subject: [SSSD] Removing uidNumberfrom SSSD Search Filter
> Date: Thu, Nov 13, 2014 9:15 AM
>
> On Thu, Nov 13, 2014 at 03:04:44PM +0000, Nathan Robbins wrote:
>> Cool. I found that in the docs : ldap_user_uid_number and ldap_user_gid_number
>>
>> I set those to an attribute in my LDAP that has a numerical value, however, still
in the query sent to my ldap server, it has (&(uidNumber=*)(!(uidNumber=0)) in the
query.
>
> Do you have enumerate=true perchance?
>
> Can you paste your sssd.conf ?
>
>>
>> Even if I set min_id = 0
>>
>> This causes my LDAP server to return no results, no matter what I do. I am ok
with mapping to another attribute, but unless I can override the search filter and get rid
of that “and” I probably won’t be able to make it work.
>>
>> Ideas?
>>
>> On Nov 13, 2014, at 3:43 AM, Jakub Hrozek
<jhrozek@redhat.com<mailto:jhrozek@redhat.com>> wrote:
>>
>>> On Wed, Nov 12, 2014 at 08:15:49PM +0000, Nathan Robbins wrote:
>>>> I would like to try and accomplish a similar result with sssd, mainly in
order to get it functioning with samba. Is is possible for me to set it up such that i
build the local user account just like above, and then use sssd *only* for
authentication?
>>>>
>>>> N
>>>
>>> The released versions of SSSD can only serve POSIX users, that is, users
>>> who have an UID and a GID. You can either point SSSD to an attribute
>>> that contains the ID or map the ID from a Windows SID.
>>>
>>> The ID attribute doesn't have to be named uidNumber/gidNumber and with
>>> recent enough version you can even use the same LDAP attribute for both.
>>> But there has to be either a numerical ID attribute or a Windows SID to
>>> derive the ID from.
>>> _______________________________________________
>>> sssd-devel mailing list
>>>
sssd-devel@lists.fedorahosted.org<mailto:sssd-devel@lists.fedorahosted.org>
>>>
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>>
>> _______________________________________________
>> sssd-devel mailing list
>>
sssd-devel@lists.fedorahosted.org<mailto:sssd-devel@lists.fedorahosted.org>
>>
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> _______________________________________________
> sssd-devel mailing list
> sssd-devel@lists.fedorahosted.org<mailto:sssd-devel@lists.fedorahosted.org>
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> _______________________________________________
> sssd-devel mailing list
> sssd-devel@lists.fedorahosted.org<mailto:sssd-devel@lists.fedorahosted.org>
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>
> _______________________________________________
> sssd-devel mailing list
> sssd-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel