On Fri, May 02, 2014 at 10:32:10AM +0200, steve wrote:
> On Fri, 2014-05-02 at 08:47 +0200, Paul Liljenberg wrote:
> >
> >
> > >On Wed, Apr 23, 2014 at 08:10:47AM +0200, Paul Liljenberg wrote:
> > >> Notice: I sent this email to the list using another mail address,
which i
> > >> believe whas not verified properly. If this emali is properly sent to
the
> > >> list you can disregard moderating the message.
> > >>
> > >> Hello
> > >>
> > >> Im setting up a single signon solution for about 1200 servers. The
> > >> situation as it seems is that we are setting up all users in a windows
2008
> > >> r2 active directory, adding proper unix permissions. A user with
proper
> > >> priveliges to read active directory is being used by sssd to read
which
> > >> users is allowed in and not. If the users does not have a home
directory
> > >> they are being created automatically. So whats the issue here? Access
to
> > >> the system does not happen instantanely and i believe its because sssd
is
> > >> polling active directory every 120 seconds. It seems as if it has
issues
> > >> remaining its state and it is just as if it would loose its local
database.
> > >> I would like to be able to have users being logged directly after a
user is
> > >> being added to active directory. Is this possible and how could this
be
> > >> achieved?
> >
> > >I would encourage you to turn enumeration off. Enumeration is a background
> > >task that periodically downloads and saves all users from the server,
> > >which can be very intensitve especially for large environments.
> >
> > >Also, is there a reason to use a bind user and a password and not a
> > >keytab and then leverage GSSAPI?
> >
> > >We have some howtos on enrolling a client with AD for pre-1.9 clients:
> >
>https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20with%20a%20Windows%202008%20Domain%20Servero
> >
> > >And also for 1.9 and later (recommended):
> > >https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
> >
> >
> > Ive edit the configuration to not use enumeration. The goal is to use
> > GSSAPI to. For some reason it refuses logins. It does not give me any
> > helpful ouput to fix it.
> >
> >
> > conf:
> >
> >
> > [sssd]
> > config_file_version = 2
> > domains = INT.HOME.LAN
> > services = nss, pam
> > debug_level = 0
> >
> >
> > [nss]
> > filter_groups = root
> > filter_users = root
> > reconnection_retries = 3
> >
> >
> > [pam]
> > reconnection_retries = 3
> >
> >
> > [domain/INT.HOME.LAN]
> > # Unless you know you need referrals, turn them off
> > ldap_referrals = false
> > # Uncomment if you need offline logins
> > cache_credentials = true
> > enumerate = false
> >
> >
> > id_provider = ldap
> > auth_provider = krb5
> > chpass_provider = krb5
> > access_provider = ldap
> >
> >
> > # Uncomment if service discovery is not working
> > ldap_uri = ldap://vagrant-2008r2.int.home.lan
> >
> >
> > # Comment out if not using SASL/GSSAPI to bind
> > ldap_sasl_mech = GSSAPI
> > # Uncomment and adjust if the default principal host/fqdn at REALM is
> > not available
> > #ldap_sasl_authid =
nfs/client.ad.example.com at
AD.EXAMPLE.COM
> >
> >
> > # Define these only if anonymous binds are not allowed and no keytab
> > is available
> > # Enabling use_start_tls is very important, otherwise the bind
> > password is transmitted
> > # over the network in the clear
> > #ldap_id_use_start_tls = True
> > #ldap_default_bind_dn = CN=test,CN=Users,DC=int,DC=home,DC=local
> > #ldap_default_authtok_type = password
> > #ldap_default_authtok = secretpassword
> >
> >
> > ldap_schema = rfc2307bis
> >
> >
> > ldap_user_search_base = CN=Users,DC=int,DC=home,DC=lan
> > ldap_user_object_class = user
> >
> >
> > ldap_user_home_directory = unixHomeDirectory
> > ldap_user_principal = userPrincipalName
> >
> >
> > ldap_group_search_base = CN=linuxadmins,DC=int,DC=home,DC=lan
> > ldap_group_object_class = group
> >
> >
> > #ldap_access_filter = memberOf=cn=linuxadmins,dc=int,dc=home,dc=lan
> >
> >
> > ldap_access_order = expire
> > ldap_account_expire_policy = ad
> > ldap_force_upper_case_realm = true
> > #ldap_krb5_init_creds = true
> >
> >
> > # Uncomment if dns discovery of your AD servers isn't working.
> > #krb5_server = 192.168.3.11
> > krb5_realm = INT.HOME.LAN
> > #krb5_keytab = /etc/krb5.keytab
> >
> >
> > # Probably required with sssd 1.8.x and newer
> > krb5_canonicalize = false
> >
> >
> > # Perhaps you need to redirect to certain attributes?
> > #ldap_user_object_class = user
> > #ldap_user_name = sAMAccountName
> > #ldap_user_uid_number = msSFU30UidNumber
> > #ldap_user_gid_number = msSFU30GidNumber
> > #ldap_user_gecos = displayName
> > #ldap_user_home_directory = msSFU30HomeDirectory
> > #ldap_user_shell = msSFU30LoginShell
> > #ldap_user_principal = userPrincipalName
> > #ldap_group_object_class = group
> > #ldap_group_name = cn
> > #ldap_group_gid_number = msSFU30GidNumber
>
> Hi
> Can you upgrade to a more recent version and use the new ad backend?
>
> If not, remember that the older versions didn't map the ad attributes to
> something we could recognise. sAMAccountName as being the Linux username
> is one I remember off the top of my head. Also, don't assume defaults.
> uncomment the lines until you get it working. We've a 1.9 config against
> AD here:
>
http://linuxcostablanca.blogspot.com.es/2013/04/sssd-in-samba-40.html
> HTH
> Steve
Right, the mappings might need to be adjusted, depending on the
environment. The upstream guide for the LDAP provider is here:
https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate...
No. That's the guide the OP used for his config. All the AD attrs are
commented so the user never gets authenticated.