[SSSD-users] SSSD, Linux Mint 14 and Samba 4 AD Server

Rowland Penny rpenny at f2s.com
Sun Mar 31 13:52:58 UTC 2013


On 29/03/13 11:21, Jakub Hrozek wrote:
> On Thu, Mar 28, 2013 at 09:22:32PM +0000, Rowland Penny wrote:
>> Hello, I am trying to use sssd instead of winbind against a samba 4
>> AD server. After looking around the internet, I have got to the
>> point where I can get a domain users info with 'getent passwd
>> <domainuser>' and 'id <domainuser>'. I can also create a directory
>> and chmod it <domainuser>:users, what I cannot do is login into the
>> computer through ssh or the login GUI on the computer. This is on
>> Linux Mint 14 using sssd 1.9.1.
>>
>> Does anybody have any idea why sssd seems to work but fails in a
>> very important way.
> Can you paste or attach tail of /var/log/secure, your (sanitized)
> sssd.conf and the relevant portion of /var/log/sssd/sssd_$domain.log
> after raising debug_level to 6 or higher in the domain section?
> _______________________________________________
> sssd-users mailing list
> sssd-users at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
OK, I thought that as sssd seemed to have started on Fedora, I would try 
it on that distro.

On Fedora 18, I can login as a domain user, but found that I have the 
same problem as with winbind, the user on the client has a different 
uidnumber to the server.

i.e
on the client:
getent passwd testuser
testuser:*:1201401105:1201400513:testuser:/home/DOMAIN/testuser:/bin/bash

on the server:
getent passwd testuser
HOME\testuser:*:3000016:100::/home/DOMAIN/testuser:/bin/bash

my sssd.conf

[sssd]
debug_level = 3
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
domains = DOMAIN
services = nss, pam

[nss]
# The following prevents SSSD from searching for the root user/group in
# all domains (you can add here a comma-separated list of system 
accounts that
# are always going to be /etc/passwd users, or that you want to filter out).
filter_groups = root,gdm
filter_users = root,gdm
reconnection_retries = 3

[pam]

[domain/DOMAIN]
description = LDAP domain with AD server
debug_level = 6
cache_credentials = true
enumerate = False

id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad

ad_server = adserver.domain.lan
ad_hostname = client.domain.lan
ad_domain = domain.lan

# Uncomment if service discovery is not working
#ldap_uri = ldap://adserver.domain.lan/

# Define these only if anonymous binds are not allowed and no keytab is 
available
ldap_default_bind_dn = CN=Administrator,CN=Users,DC=domain,DC=lan
ldap_default_authtok_type = password
ldap_default_authtok = Pa$$w0rd*

ldap_schema = rfc2307bis

ldap_search_base = dc=domain,dc=lan

# It looks like the ?sub?search notation is also accepted: 
http://sgallagh.wordpress.com/2011/12/22/sssd-tips-and-tricks-vol-2-ldap/
#ldap_user_search_base = cn=Users,dc=domain,dc=lan?sub?uid=*
ldap_user_search_base = dc=domain,dc=lan
ldap_user_object_class = person

ldap_user_home_directory = unixHomeDirectory
ldap_user_principal = userPrincipalName
ldap_user_name = sAMAccountName
ldap_user_gecos = displayName
ldap_user_uuid = objectGUID
ldap_user_modify_timestamp = whenChanged

ldap_group_search_base = dc=domain,dc=lan
ldap_group_object_class = group
ldap_group_name = sAMAccountName
ldap_group_uuid = objectGUID
ldap_group_modify_timestamp = whenChanged
ldap_group_nesting_level = 2

ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = True

ldap_pwd_policy = none

krb5_server = adserver.domain.lan
krb5_realm = DOMAIN.LAN
dns_discovery_domain = domain.lan

# Probably required with sssd 1.8.x and newer
krb5_canonicalize = false

# Uncomment if using SASL/GSSAPI to bind and a valid /etc/krb5.keytab exists
#ldap_sasl_mech = GSSAPI
# Uncomment and adjust if the default principal host/fqdn at REALM is not 
available
#ldap_sasl_authid=CLIENT$@DOMAIN.LAN


Is there anyway to get the clients to have the same uidNumber & 
gidNumber as on the server?

Rowland

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



More information about the sssd-users mailing list