sssd as a replacement for nss /pam ldap configuration
by houston
We are running sssd in place of nscd on our rhel5 servers and in place of nslcd on our rhel6 servers.
On our rhel5 boxes there appears to be a dependency on the legacy nss_ldap package and our /etc/ldap.conf .
I am curious if this is due to a lack of configuration of our sssd.conf or if it is common to keep all these different modules to keep ldap authentication working.
thx,
H
11 years, 2 months
SSSD GSSAPI Question
by Derek Page
Hi Devs,
I am using SSSD with kerberos with gssapi auth and it works really
well for our environment using AD for authentication.
I am not sure if this is an SSSD issue but I though I would ask since
I can't find a solution anywhere.
SSH'ing from system to system works great using GSSAPI passing along
your kerberos ticket. But seems to only work with its FQDN or
shortname.
The issue I have is we run Virtual IP's with different A records that
point to services for our systems. When I ssh to one of these A
records Kerberos/sssd seems to reject and GSSAPI authenticaion that is
not directed due to reverse dns mismatch.
I have disabled reverse rdns in kerberos.
I think this could also be the issue.
ldap_sasl_authid = M4DEPLOY01$(a)MY.DOMAIN.COM
Is there a way to tell sssd to accept anything?
Let me know if this is not an SSSD issue and I will leave you guys
along. However we really need this to work otherwise I have to go back
to using SSH keys, which I really don't want to. I really like the
security of krb tickets.
rpm -qa | egrep 'sssd|krb'
sssd-client-1.8.0-32.el6.x86_64
sssd-1.8.0-32.el6.x86_64
krb5-devel-1.9-33.el6_3.3.x86_64
pam_krb5-2.3.11-9.el6.x86_64
krb5-libs-1.9-33.el6_3.3.x86_64
krb5-workstation-1.9-33.el6_3.3.x86_64
My sssd.conf
[domain/default]
cache_credentials = fasle
[sssd]
config_file_version = 2
domains = my.domain.com
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
[nss]
filter_groups = root, appl, mysql
filter_users = root, mirror, appl, mysql, bamboo, puppet
reconnection_retries = 3
[pam]
reconnection_retries = 3
[domain/my.domain.com]
cache_credentials = true
enumerate = true
min_id = 80
max_id = 30000
id_provider = ldap
auth_provider = krb5
ldap_uri = ldap://ad3.my.domain.com/,ldap://ad4.my.domain.com/,ldap://ad8.my.domain....
ldap_schema = rfc2307bis
ldap_user_search_base = <REMOVED FOR SECURITY>
ldap_user_object_class = person
ldap_user_modify_timestamp = whenChanged
ldap_user_home_directory = unixHomeDirectory
ldap_user_shell = loginShell
ldap_user_principal = userPrincipalName
ldap_group_search_base = OU=Security Groups,DC=skydive,DC=runwaynine,DC=com
ldap_group_object_class = group
ldap_group_modify_timestamp = whenChanged
ldap_group_nesting_level = 5
ldap_account_expire_policy = ad
ldap_sasl_authid = M4DEPLOY01$(a)MY.DOMAIN.COM
ldap_krb5_init_creds = true
ldap_pwd_policy = mit_kerberos
chpass_provider = krb5
ldap_sasl_mech = GSSAPI
krb5_realm = MY.DOMAIN.COM
krb5_validate = true
ldap_user_name = sAMAccountName
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_user_home_directory = unixHomeDirectory
ldap_user_shell = loginShell
ldap_user_principal = userPrincipalName
ldap_group_object_class = group
ldap_group_name = sAMAccountName
ldap_group_gid_number = gidNumber
ldap_force_upper_case_realm = true
ldap_referrals = false
# User Group and Account Access
access_provider = simple
simple_allow_groups = m4_login
my krb.conf
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = MY.DOMAIN.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
default_tgs_enctypes = rc4-hmac aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
default_tkt_enctypes = rc4-hmac aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
permitted_enctypes = rc4-hmac aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
rdns = false
[realms]
MY.DOMAIN.COM = {
kdc = ad3.my.domain.com:88
kdc = ad4.my.domain.com:88
admin_server = ad3.my.domain.com
default_domain = my.domain.com
}
[domain_realm]
.my.domain.com = MY.DOMAIN.COM
my.domain.com = MY.DOMAIN.COM
11 years, 2 months
The future of the 1.5 and 1.8 LTM branches
by Jakub Hrozek
Hi,
As you may know, some SSSD releases are designated as Long Term
Maintenance releases and maintained for much longer time than regular
releases, making them suitable for use in distributions such as RHEL,
SLES or Ubuntu LTM. The current maintenance policy was announced here:
https://lists.fedorahosted.org/pipermail/sssd-devel/2011-January/005474.html
However, when RHEL6.4 is released, it will also include a rebase of SSSD
to 1.9. That will get us into a strange situation, because on one hand,
most upstream developers are most familiar with RHEL and Fedora, but the
only other supported release still using the LTM 1.8 branch will be
Fedora 17.
As the tentative plan for RHEL6 is to stay on the 1.9 branch, I think it
makes sense to proclaim 1.9.4 the next LTM release. In particular, I'd
like to do the following:
1) Release 1.5.17 with the fixes that accumulated since 1.5.16.
These are: git log --oneline sssd-1_5_16..sssd-1-5
1.5.17 would be the last 1.5 release and the 1.5 branch would become
EOL upstream.
2) 1.9.4 would be declared the next LTM release. The 1.9 branch would
still receive bugfixes, but very few (if any) new features. New feature
development would happen on the 1.10 and later branches. We are tracking
only a couple of known bugs in the 1.9 series and no known regressions
at the moment, so I think 1.9.4 is ready quality wise.
3) The 1.8 branch will only receive the most important and security
patches from now on. It wouldn't go completely unmaintained, of course,
as I suspect many users and distributions run 1.8.x
4) At some point, another future release would be named the next LTM and
1.8 will go completely EOL about a year from that point. It is not
decided yet which release will be the next LTM. Probably not 1.10,
but rather 1.11 or even later, depending on what our long term plans
(including RHEL7) will look like.
Does the above sound reasonable?
11 years, 2 months