ldap_sasl_mech EXTERNAL and SSL client authc
by Michael Ströder
HI!
Is it possible to use SASL/EXTERNAL when connecting to a LDAP server with
StartTLS or LDAPS using client certs?
In a project they have certs in all systems anyway (because of using puppet)
and I'd like to let the sssd instances on all the systems authenticate to the
LDAP server to restrict visibility of LDAP entries by ACL. I'd like to avoid
having to set/configure passwords for each system's sssd.
Ciao, Michael.
8 years, 8 months
Re: [SSSD-users] Problem with sssd and udev
by John Bossert
>> On Mon, May 20, 2013 at 08:59:28PM +0000, John Bossert wrote:
>> /var/log/messages suggests that udev starts before sssd:
>>
>> May 17 16:54:07 seadv01-db01 kernel: udev: starting version 147
>> May 17 16:54:09 seadv01-db01 sssd: Starting up
> On Tue, May 21, 2013 at 09:01:53 -0700, Jakub Hrozek wrote:
> I haven't found the bug Stephen was referring to (though I remember
> there was one as well) but if udev needs a remote user, then it should
> be starting after the SSSD.
Does this suggest a different bug - that sssd should be started before udev? If so, how should it be submitted?
10 years, 6 months
passwd: Authentication token manipulation error
by Harris, Bryan L.
Howdy folks,
I'm having an issue with password resets which I'm sorry to say I haven't been able to figure out by google search or searching the mailing list archives.
I tried to make my sssd configuration as minimal as possible following the doc on the wiki about authenticating to 2008 AD server (see [3] below) and I used the keytab method and instead of editing PAM files I ran authconfig because I'm on Red Hat.
When I switch (su - bryan.harris.adm) to my AD user and run passwd, it allows me to type both old and new passwords. Right away it says "Password change failed." Then after about 2 seconds it says "passwd: Authentication token manipulation error" on a new line.
I found [1] and [2] below which seem similar to my issue. I have played a bit with my PAM options, but to no avail. Can anyone tell me what I'm doing wrong? I can post the huge log messages, I just didn't want the email to get too large straight away.
[1] - https://bugs.launchpad.net/ubuntu/+source/libpam-krb5/+bug/826989
[2] - https://lists.fedorahosted.org/pipermail/sssd-users/2012-July/000041.html
[3] - https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20with%20a%20Windows%202008%20Domain%20Server
RHEL 6.4
pam-1.1.1-13
sssd-1.9.2-82
--- first off here is what I added to the my.great.domain zone in BIND ---
_ldap._tcp 1D IN SRV 0 100 389 dc01 _ldap._tcp 1D IN SRV 0 100 389 dc02 _kerberos._tcp 1D IN SRV 0 100 88 dc01 _kerberos._tcp 1D IN SRV 0 100 88 dc02 _kpasswd._tcp 1D IN SRV 0 100 464 dc01 _kpasswd._tcp 1D IN SRV 0 100 464 dc02
_kerberos._udp 1D IN SRV 0 100 88 dc01 _kerberos._udp 1D IN SRV 0 100 88 dc02 _kpasswd._udp 1D IN SRV 0 100 464 dc01 _kpasswd._udp 1D IN SRV 0 100 464 dc02
The rest of the files below are on linux-server.
--- /etc/pam.d/system-auth ---
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_fprintd.so auth sufficient pam_unix.so try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth sufficient pam_krb5.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account [default=bad success=ok user_unknown=ignore] pam_krb5.so account required pam_permit.so
password requisite pam_cracklib.so maxrepeat=3 difok=4 lcredit=-1 ocredit=-1 ucredit=-1 dcredit=-1 try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow try_first_pass remember=24 use_authtok password sufficient pam_sss.so use_authtok password sufficient pam_krb5.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_oddjob_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so session optional pam_krb5.so
--- /etc/pam.d/password-auth ---
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth sufficient pam_krb5.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account [default=bad success=ok user_unknown=ignore] pam_krb5.so account required pam_permit.so
password requisite pam_cracklib.so maxrepeat=3 difok=4 lcredit=-1 ocredit=-1 ucredit=-1 dcredit=-1 try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow try_first_pass use_authtok password sufficient pam_sss.so use_authtok password sufficient pam_krb5.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_oddjob_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so session optional pam_krb5.so
--- /etc/krb5.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.GREAT.DOMAIN
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = yes
[realms]
MY.GREAT.DOMAIN = {
}
[domain_realm]
my.great.domain = MY.GREAT.DOMAIN
.my.great.domain = MY.GREAT.DOMAIN
--- /etc/krb5.keytab ---
# This has the keytab from the 2008 AD domain controller.
--- /etc/sssd/sssd.conf ---
[domain/default]
cache_credentials = False
krb5_realm = MY.GREAT.DOMAIN
auth_provider = krb5
chpass_provider = krb5
debug_level = 9
[sssd]
config_file_version = 2
domains = MY.GREAT.DOMAIN
services = nss, pam
debug_level = 9
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
debug_level = 9
[pam]
reconnection_retries = 3
debug_level = 9
[domain/MY.GREAT.DOMAIN]
enumerate = True
cache_credentials = False
id_provider = ldap
access_provider = ldap
ldap_access_filter = memberOf=CN=Linux Admins,OU=Security Groups,OU=Groups,OU=MYGROUP,DC=my,DC=great,DC=domain
auth_provider = krb5
chpass_provider = krb5
debug_level = 9
ldap_schema = rfc2307bis
ldap_force_upper_case_realm = True
ldap_sasl_mech = gssapi
ldap_sasl_authid = host/linux-server.my.great.domain(a)MY.GREAT.DOMAIN
ldap_uri = ldap://dc01.my.great.domain/,ldap://dc02.my.great.domain
ldap_user_name = sAMAccountName
ldap_user_object_class = person
ldap_group_object_class = group
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_user_modify_timestamp = whenChanged ldap_user_home_directory = unixHomeDirectory ldap_user_shell = loginShell ldap_user_principal = userPrincipalName ldap_user_gecos = displayName
ldap_krb5_keytab = /etc/krb5.keytab
ldap_krb5_ticket_lifetime = 86400
krb5_realm = MY.GREAT.DOMAIN
#krb5_kpasswd = dc01.my.great.domain
#krb5_server = dc01.my.great.domain,dc02.my.great.domain
krb5_validate = true
krb5_canonicalize = false
krb5_renewable_lifetime = 7d
krb5_lifetime = 24h
krb5_use_fast = try
--- grep -i error /var/log/secure ---
May 30 08:43:26 linux-server passwd: pam_sss(passwd:chauthtok): system info: [Generic error (see e-text)] May 30 08:43:26 linux-server passwd: pam_sss(passwd:chauthtok): Password change failed for user bryan.harris.adm: 20 (Authentication token manipulation error
--- /var/log/sss/* ---
I am not sure what's relevant, I just posted some error lines. If needed I can (A) truncate the files + (B) re-run passwd and then post the results. I ignored the DNS errors after I noticed in the logs that it's correctly resolving everything afterwords because it does a lookup on the SRV record (which I added to my BIND server), or at least it looks to be correct AFAICS.
ldap_child.log: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP
ldap_child.log: Received error from KDC: -1765328359/Additional pre-authentication required ...
sssd_nss.log: Got reply from Data Provider - DP error code: 3 errno: 19 error message: Subdomains back end target is not configured
sssd_nss.log: Got reply from Data Provider - DP error code: 0 errno: 0 error message: Success ...
sssd_MY.GREAT.DOMAIN.log: Could not get fully qualified name for host name linux-server.my.great.domain error [2]: No such file or directory, resolver returned: [4]: Domain name not found
Thanks in advance,
Bryan
10 years, 6 months
Fwd: [Freeipa-users] Fedora 19 test day: OTP based 2FA using FreeIPA
by Dmitri Pal
Hello,
The following Fedora 19 test day might be of interest for the SSSD
community too.
Thanks
Dmitri
-------- Original Message --------
Subject: [Freeipa-users] Fedora 19 test day: OTP based 2FA using FreeIPA
Date: Tue, 28 May 2013 11:41:16 -0400
From: Dmitri Pal <dpal(a)redhat.com>
Reply-To: dpal(a)redhat.com
Organization: Red Hat
To: freeipa-users(a)redhat.com <freeipa-users(a)redhat.com>
The FreeIPA team is happy to welcome you to a Fedora Test Day that is
being held on Thursday, June 6th.
We invite you to take part in testing of the new OTP authentication
feature that will become available in upcoming FreeIPA 3.2 upstream
release and will be a part of Fedora 19. The feature is based on the new
extended capabilities of the MIT Kerberos [1] and 389 directory server [2].
The feature would allow users to authenticate against FreeIPA and
acquire Kerberos tickets using either OTP tokens issued by 3rd party
vendors or by FreeIPA server itself.
In the case the token is provided by a 3rd party vendor like RSA, VASCO,
Yubico, etc. the authentication data is forwarded to the external
authentication server over RADIUS protocol. In this scenario user input
is supposed to consist of the two factors as prescribed by the vendor
and will be handled by the external server. In case the OTP token is
issued by FreeIPA itself the user can authenticate using two factors one
of which is his Kerberos password and another one is a token issued for
him. A token can be provisioned to his mobile device and used via Google
authenticator app.
This is an initial phase of the first ever integrated two factor
authentication solution leveraging Kerberos SSO. When complete, users
will be able to authenticate using different authentication methods and
acquire tickets that will allow them to access different services
within the enterprise depending on the strength of their authentication.
More detailed information about the feature can be found here:
https://fedoraproject.org/wiki/Feature/FreeIPA_Two_Factor_Authentication
To read more about the test day and suggested tests see the following
link
https://fedoraproject.org/wiki/Test_Day:2013-06-06_FreeIPA_Two_Factor_Aut...
Thank you for your help and participation!
FreeIPA team
[1] http://k5wiki.kerberos.org/wiki/Projects/OTPOverRADIUS
[2] https://github.com/nkinder/otp_plugin
_______________________________________________
Freeipa-users mailing list
Freeipa-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
10 years, 6 months
creating the temp file for SELinux data failed
by Sigbjorn Lie
Hi,
I just updated SSSD on some RHEL servers, and after the upgrade I could not log on to 2 of the
machines.
The new version we're:
sssd-client-1.9.2-82.7.el6_4.x86_64
sssd-1.9.2-82.7.el6_4.x86_64
I started sssd in debug mode and an error was displayed:
(Thu May 23 22:31:58 2013) [sssd[pam]] [write_selinux_login_file] (0x0040): creating the temp file
for SELinux data failed. /etc/selinux/targeted/logins/monmEKiSb(Thu May 23 22:31:58 2013)
[sssd[pam]] [pam_reply] (0x0100): blen: 33
I proceeded to create the /etc/selinux/targeted/logins directory, restarted sssd, and now it works
OK.
Most machines upgraded without this issue.
Is this an already known bug?
Regards,
Siggi
10 years, 6 months
Problem with sssd and udev
by John Bossert
Am fighting a battle with sssd/ldap and udev (RHEL6/Centos6).
I have a udev rule that sets disk ownership to oracle/asmadmin at boot. The user oracle and group asmadmin are registered in ldap.
Other (udev) forums suggest that udev is executing before networking is enabled, ergo ldap is unreachable and the disks remain owned by root/root. Hmmm, could sssd caching be a solution?
Following the various tutorials, I've enabled sssd, with "cache_credentials = TRUE" in sssd.conf, but I'm still seeing the same results. Either sssd caching isn't happening, or udev isn't making use of it.
# getent --service=sss passwd oracle
oracle:*:550:400:Oracle User:/home/oracle:/bin/bash
# getent --service=sss group asmadmin
asmadmin:*:403:oracle
Any guidance, either to solve the problem else to obtain some useful diagnostics?
John
10 years, 6 months
Caching/performance issues with 1.5 vs 1.9
by Joshua C. Endries
Hello,
I'm trying to get sssd going here to hook up with AD/LDAP for user and group lookup. I have it working, and it works great on RHEL5 (sssd v1.5.1). Running 'id' on myself takes 3s when in foreground mode, and 0.014s in service mode (service start...). Unfortunately, on RHEL6 (sssd v1.9.2), Running 'id' on myself takes 3-4min in foreground and 1min in service mode. This is with the same sssd.conf file.
It looks like, when I look up my groups, it ends up looking up all the users in those groups, which 1.5 doesn't seem to do. We have a huge directory and caching all of this seems like a huge waste of resources... Is there a way to turn this off or modify this behavior? I tried reducing ldap_group_nesting_level but it didn't make a difference. Using ad instead of rfc2307bis didn't either. I didn't see anything else that looked like it would help...
Thanks,
Josh
10 years, 6 months
How to change autofs auto.master name?
by C. S.
Hi folks,
We have two auto.master maps: auto_master_a and auto_master_b. The reason
for this is that it allows us to maintain the same paths at different
campuses and redirect them to local filers vs. traversing a WAN link.
In sssd I don't see an option to change the auto.master map name however,
the cache expiring code seems to be hard coded to the string "auto.master".
Looking at the code briefly I'm also not quite sure what the best way to
add an ldap_autofs_master_map_name option would be, since it doesn't look
like the configuration contexts are available in the provider and be code.
Any suggestions appreciated.
Thanks!
cs
10 years, 6 months
Re: [SSSD-users] Problem with sssd and udev
by John Bossert
Sorry for leaving out specifics.
$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.3 (Santiago)
$ sssd -version
1.8.0
The problem is that, during boot, udev is not correctly executing a rule to set user/group ownership, where the target user and group are maintained (exclusively) in LDAP. If, after boot, I re-execute start_udev, all works as expected.
10 years, 6 months