On 02/04/13 11:09, Jakub Hrozek wrote:
On Sun, Mar 31, 2013 at 02:52:58PM +0100, Rowland Penny wrote:
> 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
> 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.
This is most probably caused by using different algorithm for ID mapping
on the server side and the client side. Can you check the winbind
configuration what are they using ? I would check for "idmap backend"
parameter in smb.conf
Alternatively, if the Samba server also has the POSIX attributes, you
could just be using those.
> on the client:
> getent passwd testuser
> on the server:
> getent passwd testuser
> my sssd.conf
> debug_level = 3
> config_file_version = 2
> reconnection_retries = 3
> sbus_timeout = 30
> domains = DOMAIN
> services = nss, pam
> # 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
> description = LDAP domain with AD server
> debug_level = 6
> cache_credentials = true
> enumerate = False
> id_provider = ad
Ah, I see you are using the new AD provider. In SSSD 1.9 the AD provider
has three advantages over using the LDAP/Kerberos providers:
1) Simplified configuration. You shouldn't be needing the attribute
mappings you used below
2) Does not require POSIX attributes to be present on the server side.
IDs can be mapped based on SIDs
3) Better performance during login (only when ID-mapping is in use)
> 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*
With the AD provider you shouldn't be needing any of the options below.
The AD provider should just default to them.
Is there a reason you are using password binds and not GSSAPI?
OK, I have removed
all the lines you suggested and getent stopped
working, examining /var/log/sssd/sssd_DOMAIN.log gives the reason:
(Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [resolve_srv_send]
(0x0400): SRV resolution of service 'AD'. Will use DNS discovery domain
(Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [resolve_srv_cont]
(0x0100): Searching for servers via SRV query '_ldap._tcp.DOMAIN'
(Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [resolv_getsrv_send]
(0x0100): Trying to resolve SRV record of '_ldap._tcp.DOMAIN'
(Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [request_watch_destructor]
(0x0400): Deleting request watch
(Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [resolve_srv_done]
(0x0020): SRV query failed: [Domain name not found]
(Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [fo_set_port_status]
(0x0100): Marking port 0 of server '(no name)' as 'not working'
(Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [set_srv_data_status]
(0x0100): Marking SRV lookup of service 'AD' as 'not resolved'
It is trying to look up the samba domain name instead of the the DNS
domain.name, re-adding the following line cures this:
dns_discovery_domain = domain.lan
I am also now using GSSAPI again, I just tried the username/password to
see if it made any difference.
> ldap_schema = rfc2307bis
> ldap_search_base = dc=domain,dc=lan
> # It looks like the ?sub?search notation is also accepted:
> #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@REALM is
> not available
> Is there anyway to get the clients to have the same uidNumber &
> gidNumber as on the server?
I think there are two options:
1) keep using the ID mapping and tailor the configuration of the ID
mapper in the SSSD so that it generates the same output as the winbind
mapper. We've done this before, it's not the nicest looking
configuration, but it works.
What sssd ID mapping seems to do is, get the last part of the SID and
add a number to the front of it, is this correct? and if so where does
the number come from? and is this the way Windows does it?
When you say 'the same output as the winbind mapper', which winbind are
you refering to, the winbind on the Samba 4 server or the winbind on the
Samba 3 client?
2) Switch to using POSIX IDs instead of mapping them from SIDs with both
winbind and SSSD. All that should be needed on the SSSD side is set:
ldap_id_mapping = False
to sssd.conf and restart the SSSD (you might need to rm the cache as
SSSD doesn't really handle UID/GID changes very well yet).
On the winbind side, I'm a little fuzzy on the details, but I believe
this could be done with "winbind nss info" configuration option.
The problem here is the use of winbind, I cannot get the idmap_ad
backend to work at all, and idmap_rid gives a different uid from the
Samba 4 server
From where I am 1) sounds like easier to implement since all you'd be
changing is sssd.conf
I am being to think that the way forward is to stop winbind on the Samba
4 server and use sssd instead.
sssd-users mailing list
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.