[SSSD-users] Re: Session Recording with sssd is not working
A better place for this question is the sssd-users list (which I've just CCed). On Fri, Jul 15, 2022 at 7:24 AM Sergio Belkin wrote: > > Hi, I've configured sssd to use session recording along with tlog but it's > not working. > > I don't use any domain for authentication, all users are local > > This my configuration files: > > **/etc/sssd/sssd.conf** > ``` > [sssd] > domains = files > services = pam, sudo, nss, ssh > > [domain/files] > id_provider = files > ``` > > Is the above configuration correct? > > And **/etc/sssd/conf.d/sssd-session-recording.conf** : > > ``` > [session_recording] > scope=all > exclude_users= > exclude_groups= > ``` > I don't find ny errors: > > ``` > [root@munster ~]# sssctl config-check > Issues identified by validators: 0 > > Messages generated during configuration merging: 0 > > Used configuration snippet files: 1 > /etc/sssd/conf.d/sssd-session-recording.conf > [root@munster ~]# systemctl status sssd > ● sssd.service - System Security Services Daemon > Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor > preset: enabled) > Active: active (running) since Wed 2022-07-13 23:40:25 -03; 9h ago >Main PID: 971 (sssd) > Tasks: 6 (limit: 38124) > Memory: 55.9M > CPU: 2.409s > CGroup: /system.slice/sssd.service > ├─ 971 /usr/sbin/sssd -i --logger=files > ├─ 1030 /usr/libexec/sssd/sssd_be --domain files --uid 0 --gid 0 > --logger=files > ├─ 1035 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files > ├─ 1036 /usr/libexec/sssd/sssd_sudo --uid 0 --gid 0 > --logger=files > ├─ 1037 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files > └─ 1038 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0 --logger=files > > jul 13 23:40:24 munster.belkin.home systemd[1]: Starting sssd.service - > System Security Services Daemon... > jul 13 23:40:24 munster.belkin.home sssd[971]: Starting up > jul 13 23:40:24 munster.belkin.home sssd_be[1030]: Starting up > jul 13 23:40:24 munster.belkin.home sssd_ssh[1038]: Starting up > jul 13 23:40:24 munster.belkin.home sssd_pam[1035]: Starting up > jul 13 23:40:24 munster.belkin.home sssd_sudo[1036]: Starting up > jul 13 23:40:24 munster.belkin.home sssd_nss[1037]: Starting up > jul 13 23:40:25 munster.belkin.home systemd[1]: Started sssd.service - System > Security Services Daemon. > jul 13 23:40:41 munster.belkin.home sssd_nss[1037]: Enumeration requested but > not enabled > ``` > > But recording sessions does not work. > > Relevant packages: > > ``` > sssd-2.7.3-1.fc36.x86_64 > tlog-12-2.fc36.x86_64 > fedora-release-common-36-17.noarch > ``` > > Please could you help me to figure out why session recording is not working? > > Thanks in advance! > > -- > -- > Sergio Belkin > LPIC-2 Certified - http://www.lpi.org > ___ > devel mailing list -- de...@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[SSSD-users] Re: how to say name of daemon? "S-S-S-D" or "TRIPLE-S-D"?
On Fri, Nov 15, 2019 at 7:57 AM Pavel Březina wrote: > > We, developers, always use S-S-S-D. I have never heard anyone saying > Triple-S-D :-) The "correct" pronunciation is "Ess Ess Ess Dee". It's just the initials. That said, some people use "Triple Ess Dee" and that's fine too. (I've also been known to jokingly refer to it as the "snake daemon" because it looks like it's hissing.) ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: Force LDAP SSL
On 04/20/2017 11:08 AM, Troels Hansen wrote: > I'm trying to force SSSD to only communicate encrypted, because of company > rules. > I think i'm missing something: > > SSSD configured with: id_provider = ad > > and DNS service resolution is enabled (default) > > I have tried about every combination of: > > ldap_id_use_start_tls = true > ldap_service_port = 636 > ldap_tls_reqcert = allow > > in sssd.conf [domain] section. > However, I can see SSSD LDAP connection over port 389. > > # netstat -tanp | grep sssd_be > tcp0 0 172.16.5.202:53520 172.16.1.241:389 > ESTABLISHED > 18080/sssd_be > > Have I just missed something? > Do I need to pull the certificates from AD to make it work. I'm not really > interested in verifying the certificates but only ensuring an encrypted > channel. > Well, first of all be aware that if you are using the AD provider, your communication across port 389 *is* encrypted using GSSAPI (Kerberos). It uses the host keytab to encrypt that communication. Using SSL atop that would be a waste of resources (and unsupported by Microsoft, if I recall correctly). If you have GSSAPI encryption available (you do) then SSSD ignores the `ldap_id_use_start_tls` argument because you don't need both encryption streams. `ldap_id_use_start_tls` tells the LDAP provider to use the STARTTLS command on port 389 to wrap communication in a secure layer. If you REALLY, wanted to use port 636, you would need to use `ldap_uri = ldaps://server.host.name` (note the "ldaps" in the URI) which tells it to use SSL-based encryption and the default port for that which is 636. I don't actually know what happens when you try this with `ad_provider=ad`, though. It's unnecessary, wasteful and possibly disallowed by Microsoft. signature.asc Description: OpenPGP digital signature ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: Error message returned to users - GPO access rules
On 01/12/2017 08:49 AM, jake.ridd...@gmail.com wrote: > The target host logs this in /var/log/secure: > > Jan 12 11:20:41 jr-centos sshd[2892]: pam_sss(sshd:auth): authentication > success; logname= uid=0 euid=0 tty=ssh ruser= rhost=[REDACTED] user=bob > > Jan 12 11:20:41 jr-centos sshd[2892]: pam_sss(sshd:account): Access denied for > user bob: 6 (Permission denied) > > Jan 12 11:20:41 jr-centos sshd[2892]: Failed password for bob from > 192.168.56.98 > port 45070 ssh2 > > Jan 12 11:20:41 jr-centos sshd[2892]: fatal: Access denied for user bob by PAM > account configuration [preauth] ... > To be clear, the configuration is working fine, I don’t expect bob to get > access > to the jr-centos server and I can get user “bob” to log in if I add him to the > relevant AD group. However, the abrupt SSH disconnection is not very user > friendly and something like “Access denied due to policy” or whatever would be > more useful. Is the lack of useful (any) message due to something in my > environment, or does this require a feature request/improvement? The line "pam_sss(sshd:account): Access denied for user bob: 6 (Permission denied)" literally means "access denied due to policy". That's what (sshd:account) is. It's the access-control check. You see just above that where (sshd:auth) reported authentication success. So the user is authenticated and the next failure is access-control. SSSD doesn't control these log messages; they come from SSH/PAM. signature.asc Description: OpenPGP digital signature ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: sssd-ad Clarifications
On 12/29/2016 09:03 AM, Jakub Hrozek wrote: >> If I configure the server to enforce STARTTLS is SSSD "smart enough" to >> work with that if I use sssd-ad or would I need to go the LDAP+Kerberos >> route in order to configure some of the TLS-related settings? >> > > The gssapi authentication is by default and cannot even be changed with > sssd-ad. > Just to clarify here: the GSSAPI used by SSSD also provides encrypted communication. You do not need to enable TLS as well (and I think SSSD will just ignore that option in this case). signature.asc Description: OpenPGP digital signature ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: finger cmd not working unless enumerate = true
On 09/07/2016 02:22 AM, Joakim Tjernlund wrote: > On Tue, 2016-09-06 at 20:51 +0200, Lukas Slebodnik wrote: >> On (06/09/16 17:36), Joakim Tjernlund wrote: >>> >>> I just get no such user unless I enumerate the domain, is that really >>> needed ? >>> sssd-1.13.4 >>> >> It's very difficult to say without log files. >> >> https://fedorahosted.org/sssd/wiki/Troubleshooting >> > > I only get a hit in sssd_nss.log when I do "finger " > > (Wed Sep 7 08:21:41 2016) [sssd[nss]] [get_client_cred] (0x4000): Client > creds: euid[1001] egid[100] pid[21947]. > (Wed Sep 7 08:21:41 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x2641510][24] > (Wed Sep 7 08:21:41 2016) [sssd[nss]] [accept_fd_handler] (0x0400): Client > connected! > (Wed Sep 7 08:21:41 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x2641510][24] > (Wed Sep 7 08:21:41 2016) [sssd[nss]] [sss_cmd_get_version] (0x0200): > Received client version [1]. > (Wed Sep 7 08:21:41 2016) [sssd[nss]] [sss_cmd_get_version] (0x0200): > Offered version [1]. > (Wed Sep 7 08:21:41 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x2641510][24] > (Wed Sep 7 08:21:41 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x2641510][24] > (Wed Sep 7 08:21:41 2016) [sssd[nss]] [nss_cmd_setpwent_send] (0x0100): > Received setpwent request > (Wed Sep 7 08:21:41 2016) [sssd[nss]] [nss_cmd_setpwent_send] (0x0040): > Enumeration disabled on all domains! > (Wed Sep 7 08:21:41 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x2641510][24] > (Wed Sep 7 08:21:41 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x2641510][24] > (Wed Sep 7 08:21:41 2016) [sssd[nss]] [nss_cmd_getpwent] (0x0100): > Requesting info for all accounts > (Wed Sep 7 08:21:41 2016) [sssd[nss]] [nss_cmd_setpwent_send] (0x0100): > Received setpwent request > (Wed Sep 7 08:21:41 2016) [sssd[nss]] [nss_cmd_setpwent_send] (0x0040): > Enumeration disabled on all domains! > (Wed Sep 7 08:21:41 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x2641510][24] > (Wed Sep 7 08:21:41 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x2641510][24] > (Wed Sep 7 08:21:41 2016) [sssd[nss]] [client_recv] (0x0200): Client > disconnected! > (Wed Sep 7 08:21:41 2016) [sssd[nss]] [client_destructor] (0x2000): > Terminated client [0x2641510][24] Definitely looks like it's trying to run setpwent(), which doesn't work without enumeration. I'm guessing that whatever implementation of `finger` you have is doing things really, really wrong. signature.asc Description: OpenPGP digital signature ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD and Active Directory loginShell and unixHomeDirectory caching problem.
On 09/07/2016 08:16 AM, Ondrej Valousek wrote: > The config you have does not make any sense, really. > Obviously you have id_mapping turned on - in this case SSSD ignores any > RFC2307 attributes in AD - including loginshell. > If you want SSSD to honour RFC2307 attrs in AD, you need to turn > ldap_id_mapping off. That statement is incorrect. ID mapping *only* applies to UID and GID. SSSD will still use the loginShell *if it is actually set*. If it's not set, then it will just use the default_shell... which is explicitly set to /sbin/nologin. More below. > > -Original Message- > From: faktoriyel [mailto:faktori...@yahoo.com] > Sent: Wednesday, September 07, 2016 1:06 PM > To: sssd-users@lists.fedorahosted.org > Subject: [SSSD-users] SSSD and Active Directory loginShell and > unixHomeDirectory caching problem. > > Hi Guys. > > This is my first question in this mailing list and I already apologize for > the missing info and logs . I use rhel 7.2 server and try the login from A.D > with pam.. These are my sssd version info > > sssd-common-pac-1.13.0-40.el7.x86_64 > sssd-krb5-1.13.0-40.el7.x86_64 > python-sssdconfig-1.13.0-40.el7.noarch > sssd-client-1.13.0-40.el7.x86_64 > sssd-krb5-common-1.13.0-40.el7.x86_64 > sssd-ad-1.13.0-40.el7.x86_64 > sssd-ldap-1.13.0-40.el7.x86_64 > sssd-proxy-1.13.0-40.el7.x86_64 > sssd-common-1.13.0-40.el7.x86_64 > sssd-ipa-1.13.0-40.el7.x86_64 > sssd-1.13.0-40.el7.x86_64 > > I have successfully join to A.D. with net ads join and start sssd service . > here is my sssd.conf file > > [sssd] > config_file_version = 2 > services = nss, pam > domains = xxx.local > > [nss] > shell_fallback = /sbin/nologin > allowed_shells = /bin/bash,/bin/sh > default_shell = /sbin/nologin > filter_groups = root > filter_users = root > > [domain/default] > cache_credentials = False > ldap_enumeration_refresh_timeout = 600 > ldap_purge_cache_timeout = 600 > > [domain/yurticikargo.local] > id_provider = ad > auth_provider = ad > chpass_provider = ad > access_provider = ad > ad_server = xx01.xx.local,xx03.xx.local > ad_domain = xx.local > ldap_krb5_keytab = /etc/krb5.keytab > ldap_krb5_init_creds = true > ldap_idmap_range_size = 1 > ldap_idmap_range_max = 200020 > ldap_schema = ad > cache_credentials = False > ldap_enumeration_refresh_timeout = 600 > ldap_purge_cache_timeout = 600 > ldap_user_shell = loginShell > > after that when I check with getent any user account. I get correct info from > active directory especially abont loginShell and unixHomeDirectory field. I > change login method to sss and login with ssh everything is fine but when I > logout and re-login user loginShell and unixHomeDirectory info dissappear and > I fall the nologin shell. > > After clean sssd cache file and fresh start sssd > > getent passwd > :*:1101569237:1101586812:x:/home/applicationadmins:/bin/bash > > after ssh login logout with user > > getent passwd > :*:1101569237:1101586812::/:/sbin/nologin > > I think sssd doesn't cache iloginShell and unixHomeDirectory info from A.D. > and when I login first time write cache some info doesn't include this > information. When I re-login it gets info from cache files and dosen't find > loginshell etc. And then I fall the nologin shell. Is tihs a bug? or am I > missing something.? > SSSD actually *only* returns data from the cache; never directly. (When the cache is empty, we go to LDAP, update the cache, then we retrieve the cached contents to return). It certainly sounds like something is causing the cache to be *overwritten*, though, which is quite odd. In this case, we really need debug logs to make any sense of it. Please read https://fedorahosted.org/sssd/wiki/Troubleshooting for details. signature.asc Description: OpenPGP digital signature ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD-PAM failure
On 08/09/2016 03:42 PM, Thomas Beaudry wrote: > (Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending > request with the following data: > (Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): command: > SSS_PAM_AUTHENTICATE > (Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): domain: > concordia.ca > (Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): user: > tbeaudry > (Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): service: su > (Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: > /dev/pts/1 > (Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): ruser: tmtg > (Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): rhost: not > set > (Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): authtok > type: 1 > (Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): newauthtok > type: 0 > (Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): priv: 0 > (Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: > 6032 > (Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): logon name: > tbeaudry > (Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_dom_forwarder] (0x0100): > pam_dp_send_req returned 0 > (Tue Aug 9 15:39:32 2016) [sssd[pam]] [sss_dp_req_destructor] (0x0400): > Deleting request: [0x410090:3:tbeau...@concordia.ca] > (Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_dp_process_reply] (0x0200): > received: [6 (Permission denied)][concordia.ca] > (Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply called > with result [6]: Permission denied. > (Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 83 > (Tue Aug 9 15:39:33 2016) [sssd[pam]] [client_recv] (0x0200): Client > disconnected! > > > Any thoughts? I am going over the troubleshooting wiki now for a 3rd time. > Thomas, this response indicates that SSSD did try to contact the authentication provider and received a response that explicitly said "this user is not permitted". Usually that means the wrong password (or sometimes expired password, if they are beyond the grace period). Please add "debug_level = 7" to the [domain/concordia.ca] section of sssd.conf, restart and then try to log in as that user again. This time, send us /var/log/sssd/sssd_concordia.ca.log and /var/log/sssd/krb5_child.log which should show us the exact reason why the user is denied. signature.asc Description: OpenPGP digital signature ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: keyring: disk quota exceeded
On 07/27/2016 08:42 AM, Ondrej Valousek wrote: > It has Gnome installed, but none is using it. If GNOME is not in use, then this can't be the same problem, sorry. This only happens if an active user is signed in to GNOME. And it only affects the current user. > I do not know what triggers it unfortunately. I just upgraded the kernel and > rebooted the machine hoping it won't come back. > I doubt Online Accounts might have caused that. > > How do I found out which keyring is causing troubles? > Tried 'keyctl show' but it did not show anything interesting... > Ondrej > Next time it happens, can you send the output of `cat /proc/keys` (as the affected user _not_ root) and `cat /proc/key-users` please? That will help. signature.asc Description: OpenPGP digital signature ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: keyring: disk quota exceeded
On 07/27/2016 08:38 AM, John Hodrien wrote: > On Wed, 27 Jul 2016, Stephen Gallagher wrote: > >> Is this on a GNOME workstation? We recently discovered a bug in GNOME Online >> Accounts that can (in rare circumstances) cause the keyring to fill up with >> garbage which ends up preventing the legitimate values from being updated). > > Have you got a BZ for this, or more details on what triggers it? > Unfortunately, we never figured out how to reproduce it, but once it starts happening, it happens on every boot. (By lucky coincidence, my personal systems hit it, so we were able to validate the fix). Upstream BZ is https://bugzilla.gnome.org/show_bug.cgi?id=768808 The patches are: * https://git.gnome.org/browse/gnome-online-accounts/commit/?id=607f9aea526e383a03ddce55e05c7488d87de872 * https://git.gnome.org/browse/gnome-online-accounts/commit/?id=517fc9c4c88fd34764d4e4aeb063c9b7bf9419fd signature.asc Description: OpenPGP digital signature ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: keyring: disk quota exceeded
On 07/27/2016 06:12 AM, Ondrej Valousek wrote: > Hi List, > > > > Or RH-7 box I am getting message like this: > > > > [root@spartacus bin]# kinit > > kinit: Disk quota exceeded while getting default ccache > > > > Google gave this: https://bugzilla.redhat.com/show_bug.cgi?id=1017683 > > > > Which suggests big keys needs to be enabled for kernel and suggests kernel > 3.11 > > However, RHEL-7 is based on 3.10 kernels – do we know whether big Kerberos > keys > are supported there? > > > Is this on a GNOME workstation? We recently discovered a bug in GNOME Online Accounts that can (in rare circumstances) cause the keyring to fill up with garbage which ends up preventing the legitimate values from being updated). signature.asc Description: OpenPGP digital signature ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: Only members of one AD group should have access to Linux login
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/20/2016 08:02 AM, Jakub Hrozek wrote:
> On Wed, Jan 20, 2016 at 12:16:50PM -, h...@miracle.dk wrote:
>> Hi
>>
>> I have several users in my AD. All of them can now login with ssh
>> to the Linux server which is not intended.
>>
>> In the AD I have the group MyTestGrp. I want only users in that
>> group to have access to this server.
>>
>> Testing on the Linux server provides the information necessary
>> ("admjoin" should not have access):
>>
>> avgjoe@host007:~$ getent passwd admjoin
>> admjoin:*:1905540256:1905400513:AdmJoin:/home/corp.acme.com/admjoin:/
bin/bash
>>
>>
avgjoe@host007:~$ getent group MyTestGrp
>> MyTestGrp:*:1905738908:avgjoe,bob
>>
>> Where should I add MyTestGrp in the configuration files?
>>
>> I have looked around in /etc/sssd/ and /etc/pam.d/ without
>> success.
>>
>> It is working now with sudo for the group members so I guess it
>> should be possible.
>
> access_provider=simple simple_allow_groups=MyTestGrp
Alternately, if you want to manage things in AD itself, you can use:
access_provider=ad
ad_gpo_access_control=enforcing
Then you can set up GPO-based access control by setting "Allow
Interactive Remote Logon" (for ssh) and "Allow Interactive Logon" (for
console/graphical login) in a GPO applied to the machine(s).
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iEYEARECAAYFAlaf4YIACgkQeiVVYja6o6PrSgCfZKMYgj+s210jOeaQvPCjVSzt
cwIAn00h3AkTfS4K7TQNJKRDZCJ5Kq8q
=e6aU
-END PGP SIGNATURE-
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
Re: [SSSD-users] Fetching Hosts Entries from OpenLDAP Database
On Thu, 2015-08-20 at 00:54 +0200, Michael Ströder wrote: Dmitri Pal wrote: On 08/19/2015 03:53 PM, Jakub Hrozek wrote: On Wed, Aug 19, 2015 at 09:49:22PM +0530, Rajnesh Kumar Siwal wrote: Any suggested workaround . You can use nss-pam-ldapd just for the hosts database and sssd for the rest, you can use different views or different servers altogether for public/private views. btw this is the first time I've heard a request for hosts support in sssd, so I don't think it's something that can be expected, unless someone steps in and implements the maps. People usually use DNS for that and it is the recommended way of doing things. BTW if you want LDAP managed host entries you can use FreeIPA and it comes with DNS to solve this issue. But DNS is not subject to access control. Yes, I also already thought about making host entries visible only to specific hosts. Hmm, access-control is the first good argument I've heard for supporting hosts in LDAP as opposed to DNS[SEC]. Historically, we've ignored the hosts map in SSSD because we reasoned that dnsmasq was a better caching solution for hosts than LDAP. However, being able to restrict what machines have access to the hosts is actually an interesting use-case. If you have a RHEL subscription, I'd encourage you to contact your support representative to make a formal request for inclusion of the hosts map in SSSD. If you do not, please file an RFE at https://fedorahosted.org/sssd with this justification and upstream will consider it for inclusion in a future release. signature.asc Description: This is a digitally signed message part ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] please do not remove enumeration from AD provider
- Original Message - From: James Ralston rals...@pobox.com To: End-user discussions about the System Security Services Daemon sssd-users@lists.fedorahosted.org Sent: Wednesday, May 6, 2015 1:28:35 PM Subject: [SSSD-users] please do not remove enumeration from AD provider On Wed, May 6, 2015 at 4:27 AM, Jakub Hrozek jhro...@redhat.com wrote: You know, just this morning, I was thinking about enumeration. It doesn't work for IPA views at all for example. It doesn't work for trusted domains at all either (except for some limited support in AD trusted domains that is very untested) I wonder if we could just remove enumeration from IPA and AD back ends in some major release. Please don't do this. Enumeration is a very useful feature. It allows us to do things like this: $ getent passwd | grep -i lastname The equivalent ldapsearch command is much more tedious: $ ldapsearch -z 0 -E pr=2147483647/noprompt -o ldif-wrap=no -L -L -H 'ldap:///dc%3Dexample%2Cdc%3Dorg -Y GSSAPI -N -b dc=example,dc=org ((objectClass=user)(cn=*lastname*)) dn cn sAMAccountName To be fair, it's not that hard to turn that into a bash script that your users can use instead of learning the ldap syntax. But yes, that's still a change in behavior. More generically, enumeration is the way Unix/Linux has always worked. Even getting users to change from: grep -i lastname /etc/passwd To this: getent passwd | grep -i lastname ...has been a struggle. We also have various services that (unfortuantely) pre-load the passwd and group files at startup by enumerating them with getpwent_r() and getgrent_r(), instead of using the get*nam_r() and get*id_r() functions as-needed. These services break outright if enumeration is disabled. (Yes, these services are broken. Yes, they shouldn't do that. But our ability to fix them is extremely limited at best, because we don't control them.) Well, as the original post to this list noted, this is already broken, with no way to fix it. When we're talking to LDAP, there's no guarantee that the server will actually let us get all of the results. Many servers are configured with a limited number of records we can retrieve (though we work around that with paging controls on servers that support them). With AD, we can only enumerate the domain the host is joined to. If your users aren't part of the same domain as the host, enumeration won't find them. Finally, we have many systems that cannot be joined to Active Directory (for policy reasons, not technical reasons). But we want to use the same passwd/group entries on those systems as returned by sssd on hosts that are joined to Active Directory. We do this by scraping the output of getent -s sss passwd and getent -s sss group and manually merging it into the local passwd and group files (respectively) on these hosts. Sorry to sound glib, but fix your policy. Let's be honest, any policy that boils down to These machines are not allowed to function with proper security controls is one that can only end in disaster. It's just a legacy feature, so those who need it can fall back to the LDAP provider.. But the LDAP provider doesn't support ID mapping; only the AD provider does. And ID mapping is the main reason we use sssd. As noted in the other reply, the LDAP provider does support ID mapping. However, you'll still have to face the same problems as above with regards to paging limits and domains other than the one the host is joined to. I'm not asking you to make enumeration the default. It shouldn't be; it should be something you only turn on if you need it, and you KNOW you need it. But if you need it, you NEED it. Please don't take it away. If you need it, you're already in bad shape. Have you heard the adage If someone is irreplaceable, replace them immediately? The same is true for software. If you have a bad system in place, it's best to rip it out as fast as possible, because otherwise the problem will continue to grow, accruing technical debt you can never hope to manage. This is one of those cases: every band-aid we apply to the enumeration support causes this to limp along on life-support and provides consumers a false sense that this is something they can rely upon. Frankly, I think it may be time to rip off the aforementioned band-aid and amputate this gangrenous limb. ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Announcing SSSD 1.12.2
On Tue, 2014-10-21 at 09:39 +0100, John Hodrien wrote: On Tue, 21 Oct 2014, Lukas Slebodnik wrote: Packages for some older distributions then fedora 21 are available in COPR http://copr-fe.cloud.fedoraproject.org/coprs/lslebodn/sssd-1-12/ Thanks for this. In RHEL7 we have sssd-client.i686 available, which gets used by things like 32bit Adobe Acrobat, else they die a death: getpwuid_r(): failed due to unknown user id Any chance the COPR could include it as well so we've got a full set to test? There are two problems here. 1) The COPR interface currently only allows building for x86_64 (because there's no i686 release of RHEL to build against. 2) Even if we could build i686 EPEL 7 binaries, COPR doesn't support pulling multilib packages into the same repository. This part could be handled with some clever repo packaging, but currently it doesn't work. signature.asc Description: This is a digitally signed message part ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Announcing SSSD 1.12.2
On Tue, 2014-10-21 at 22:02 +0200, Lukas Slebodnik wrote: On (21/10/14 15:42), Stephen Gallagher wrote: On Tue, 2014-10-21 at 15:22 -0400, Simo Sorce wrote: On Tue, 21 Oct 2014 09:39:07 +0100 (BST) John Hodrien j.h.hodr...@leeds.ac.uk wrote: On Tue, 21 Oct 2014, Lukas Slebodnik wrote: Packages for some older distributions then fedora 21 are available in COPR http://copr-fe.cloud.fedoraproject.org/coprs/lslebodn/sssd-1-12/ Thanks for this. In RHEL7 we have sssd-client.i686 available, which gets used by things like 32bit Adobe Acrobat, else they die a death: getpwuid_r(): failed due to unknown user id Any chance the COPR could include it as well so we've got a full set to test? As work around you could force install RHEL's native i686 client. The client protocol hasn't changed (not in incompatible ways anyway) so it should keep working. That's true of the NSS and PAM clients, but I'm not certain about the PAC client or the Kerberos localauth client. You might have better luck force-installing the fc20 or fc21 sssd-client.i686 package. Hard to say for sure, though. The safest(not the easiest :-) way would be to rebuild srpm locally. rpmbuild --buildarch i486 --rebuild sssd.src.rpm Impossible, because they won't have the build dependencies available on the correct architecture. signature.asc Description: This is a digitally signed message part ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] sssd users and systemd services?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/15/2014 01:53 PM, Nordgren, Bryce L -FS wrote: Do I get it right that you are not actually trying to run systemd itself as a user but to start a service by systemd that will run as an SSSD user. You might have chicken and egg problem because the user might not be available until SSSD is started and running. So I think the service you are trying to start should be dependent on SSSD and make sure that SSSD is running. Sorry if I misunderstood what you are trying to do. Dmitri Sorry for not getting back to you earlier, I missed your response. Correct: I'm not altering who runs system itself, but trying to run my ipython-notebook service as my own domain user account. I can't even get it to work manually, after I've logged in using the account with which I'm trying to run the service. Sorry the following is ellipsized, I can only get to the non-ellipsized parts with journalctl and a pager, but they really don't add value. The important part is code=exited, status=217/USER, which is a systemd code, not an ipython code: [bnordgren@lugosi ~]$ sudo systemctl start ipython-notebook [bnordgren@lugosi ~]$ sudo systemctl status ipython-notebook ipython-notebook.service - IPython notebook service Loaded: loaded (/etc/systemd/system/ipython-notebook.service; enabled) Active: failed (Result: exit-code) since Mon 2014-09-15 11:45:32 MDT; 7s ago Process: 15558 ExecStart=/bin/ipython notebook (code=exited, status=217/USER) Sep 15 11:45:32 lugosi.usfs-i2.umt.edu systemd[1]: Starting IPython notebook ... Sep 15 11:45:32 lugosi.usfs-i2.umt.edu systemd[1]: Started IPython notebook s... Sep 15 11:45:32 lugosi.usfs-i2.umt.edu systemd[1]: ipython-notebook.service: ... Sep 15 11:45:32 lugosi.usfs-i2.umt.edu systemd[1]: Unit ipython-notebook.serv... [bnordgren@lugosi ~]$ sudo cat /etc/systemd/system/ipython-notebook.service [Unit] Description=IPython notebook service After=syslog.target network.target [Service] Type=simple User=bnordgren ExecStart=/bin/ipython notebook KillMode=process Environment=PYTHONPATH=/home/bnordgren/src/pylsce [Install] WantedBy=multi-user.target [bnordgren@lugosi ~]$ getent passwd bnordgren bnordgren:*:10001:1:Nordgren, Bryce L -FS:/home/bnordgren:/bin/bash [bnordgren@lugosi ~]$ /bin/ipython notebook [NotebookApp] Using existing profile dir: u'/home/bnordgren/.ipython/profile_default' [NotebookApp] Serving notebooks from /home/bnordgren/notebooks [NotebookApp] The IPython Notebook is running at: http://[all ip addresses on your system]:/ipython/ [NotebookApp] Use Control-C to stop this server and shut down all kernels. I just attempted to reproduce this issue on Fedora 21 Alpha with: systemd-215-14.fc21.x86_64 sssd-1.12.1-1.fc21.x86_64 Everything worked exactly as expected. I suspect there was a bug in either systemd or SSSD in Fedora 19 that has been subsequently addressed. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQZhRYACgkQeiVVYja6o6NxbgCfVmENC9/2MaQ/iOtLLWUTwTMh 29wAoKNG6dYLo5d4GC9ZIGueopMAjUOy =Oa5v -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] SSSD current config dump
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/18/2014 06:06 AM, Jakub Hrozek wrote:
On Thu, Jul 17, 2014 at 12:54:54PM -0300, Felipe Pereira wrote:
Is there a way to dump all config settings?
I'd like to know the defaults configured for everything I didn't
set in the sssd.conf.
If you bump the debug_level of a domain to 0x0400 you will see the
backend configuration options. The output looks similar to this one
from my test setup:
(Fri Jul 18 06:06:30 2014) [sssd[be[win.example.com]]]
[dp_get_options] (0x0400): Option ad_domain has value
win.example.com (Fri Jul 18 06:06:30 2014)
[sssd[be[win.example.com]]] [dp_get_options] (0x0400): Option
ad_server has no value (Fri Jul 18 06:06:30 2014)
[sssd[be[win.example.com]]] [dp_get_options] (0x0400): Option
ad_backup_server has no value (Fri Jul 18 06:06:30 2014)
[sssd[be[win.example.com]]] [dp_get_options] (0x0400): Option
ad_hostname has no value (Fri Jul 18 06:06:30 2014)
[sssd[be[win.example.com]]] [dp_get_options] (0x0400): Option
krb5_keytab has no value (Fri Jul 18 06:06:30 2014)
[sssd[be[win.example.com]]] [dp_get_options] (0x0400): Option
krb5_realm has value WIN.EXAMPLE.COM (Fri Jul 18 06:06:30 2014)
[sssd[be[win.example.com]]] [dp_get_options] (0x0400): Option
ad_enable_dns_sites is TRUE (Fri Jul 18 06:06:30 2014)
[sssd[be[win.example.com]]] [dp_get_options] (0x0400): Option
ad_access_filter has no value (Fri Jul 18 06:06:30 2014)
[sssd[be[win.example.com]]] [dp_get_options] (0x0400): Option
ad_enable_gc is TRUE (Fri Jul 18 06:06:30 2014)
[sssd[be[win.example.com]]] [dp_get_options] (0x0400): Option
ad_gpo_access_control has value permissive
That doesn't describe the responder options or monitor options, though.
I think what you want to do is use the SSSDConfig python API, which
you can use to see all of the options and their current values.
Unfortunately, it's not well documented (outside of the pydoc in the
source), but the general approach would be something like:
(as root)
import SSSDConfig
cfg = SSSDConfig.SSSDConfig()
cfg.import_config()
print cfg.list_services()
svc = cfg.get_service('nss')
opt_dict = svc.list_options()
print cfg.list_domains()
dom = cfg.get_domain('example.com')
dom_opt_dict = dom.list_options()
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlPOcuMACgkQeiVVYja6o6OONACeJ14PHlrZWJkSWZY1RS4Uunxl
9WEAnRjG+bPIWUaAFQ4x2cmYGOr2Hvzx
=5iyu
-END PGP SIGNATURE-
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] LDAP access provider - list of groups in directory?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/09/2014 05:28 PM, Jakub Hrozek wrote: On 07 Jul 2014, at 11:00, John Snowdon john.snow...@newcastle.ac.uk wrote: Hi, I'm currently working on an sssd configuration to replace a set of legacy authentication and authorization mechanisms on several hundred Linux systems in our department - they're currently supported via shared /etc/passwd and /etc/group files. I've got access, user and group information all working well via pam and sssd and am now trying to find a solution to the authorisation requirements. Previously this was managed via puppet-distributed changes to /etc/pam.d with a list of users/groups per machine stored in the puppet nodes files. I'd like to move to a setup where each machine (or class of machine) just pulls the list of allowed unix groups from it's own node in OpenLDAP. Is there anything available in sssd.conf that would allow the ldap access provider to pull back a list of allowed groups from ldap, rather than listing them explicitly? Sort of a hybrid between the simple_allow_groups and ldap_access_filter? e.g. What I would love to do access_provider = ldap ldap_allow_groups_dn = cn=MachineA,ou=machines,dc=network,dc=com Where the cn=MachineA object is a groupOfNames that would look something like: objectClass: groupOfNames objectClass: top cn: MachineA description: Posix groups whose users are allowed to access MachineA member: root member: localusers member: adminusers member: webusers I'd much rather have the lists of groups allowed to access a machine managed from LDAP, rather than directly coded into sssd.conf, or alternatively, via pam_listfile. Is there any way of enabling this in the current version of sssd, or emulating it somehow via ldap_access_filter? Cheers, John Hi John, The one-sentence answer is not easily, sorry. The thing about ldap_access_filter to keep in mind is that the filter is applied on the /user entry/ when the user logs in. Basically, the ldap_access_filter is AND-ed with a filter that involves the user entry, if there is a match, the access is allowed, otherwise the access is denied. One solution I can think about is to use the memberof overlay with OpenLDAP and then employ a filter on the client side that would include memberof=allowed_group_dn. But to be honest, I don’t have too much experience with the memberof overlay, so I’m not sure if this suggestion would work for nested groups for example. I hope the explanation on how the ldap_access_filter works is still useful. Please let us know if you have any more questions! I think what John is really asking for is the simple access provider with one significant enhancement: the ability to specify the contents of the access-lists in LDAP. John, this would actually be a rather interesting idea, but I agree with Dmitri: if this is the level of control that you need, you would be in a far better position with FreeIPA/Red Hat Identity Management. It has this concept baked into its Host-Based Access Control mechanism (which SSSD fully supports). The problem with trying to do this in plain LDAP is that there exists no standard mechanism for maintaining this sort of information on the LDAP server (FreeIPA's HBAC rules are kind of a de-facto standard). -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO+ffQACgkQeiVVYja6o6MK2ACfaF5IctMKV0k/YpNC+Vhe3NMl IToAn3nJNC/36XCl7h7xUe4/jjpF8qsS =TPY5 -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] timeout and offline mode behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/02/2014 07:51 AM, John Hodrien wrote: On Mon, 2 Jun 2014, Stephen Gallagher wrote: This is the real problem. If SSSD can route to the IP address, then we have to proceed assuming that the LDAP server should be available (thereby attempting to connect to it and perform online authentication). There's really no way to determine ahead of time whether the service is supposed to be available. You may want to play with the option 'ldap_opt_timeout' (see sssd-ldap(5)). It controls how long the OpenLDAP client libraries will wait for a response (in your case, how long it will wait while the packets are dropped. It defaults to 6s). This should be a one off hit though, right? If I discover the LDAP server is offline, I should remember this, admittedly recheck periodically, but never cause another delay waiting for it to spring back into life. Given the way some of these laptops are used, I'd even quite like to configure it to default to this state. When I last tried this (which was a while ago) these delays would happen repeatedly, so the setup was unusable, and I had to ditch sssd on the laptop. Well, in most common cases, the LDAP server is unresolvable when not on the VPN/inside the network, so SSSD immediately detects that it can't get there and the delay is unnoticeable. It's those cases where the server is addressable but unresponsive that is much harder to handle. Right now, we have a two-minute sleep between operations trying to go online again. (I think I saw a patch go in for 1.12 that makes this configurable). That's mostly so that we catch cases where you've connected to the VPN but for one reason or another SSSD doesn't get notified that the network state changed (there are lots of edge-cases that cause this). -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOMadkACgkQeiVVYja6o6MAcwCeNIGfCAQyhaKagU1vPt5hm1aj RroAnjebqWadxdN01yL+Sdspms1jDFVh =UAAQ -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] timeout and offline mode behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/29/2014 07:40 AM, Jakub Hrozek wrote: On Mon, Apr 21, 2014 at 10:05:58AM -0400, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/17/2014 04:13 AM, Jakub Hrozek wrote: On Wed, Apr 16, 2014 at 10:47:10PM -0400, Simo Sorce wrote: On Wed, 2014-04-16 at 19:49 -0400, Dmitri Pal wrote: I had some interesting experience during Red Hat summit. The network was significantly overloaded. The VPN was slow and probably bleeding packets on the way like crazy. Any access to internal web page took a while and was happening in multiple steps. When screen was locking it was taking about 30 sec (I have not measured but that was a feeling) to log in. I am not sure we can do much about it but the flaky network is probably going to lead to some timeouts and bad user experience. I think this may be a recent regression. We are never supposed to wait more than a handful of seconds, but I am noticing that with latest RHEL6 updates my RHEL desktop also sometimes gets stuck a while on authentication (VPN). I have not experienced this in F20 (but my domain controller is local). Simo, if you can reproduce the error locally, would you mind enabling debug logs or trying out the 6.6 preview packages? I only have headless VMs with RHEL6 and I'm not sure I could reproduce the bug there. But it sounds like something we should fix, so any debug information would be welcome, at least to know where to start with local debugging. btw when I tried to reproduce the bug Thomas was seeing, I saw some blocking DNS calls in openldap's initialization path, but that was on F-20. OpenLDAP isn't supposed to be calling DNS at all. That's the entire reason we open the port ourselves now and then pass the FD to it. If it suddenly started running DNS, that's probably a regression in the openldap libraries. I had a bit of time to dig into the issue today, here is a snippet of the backtrace I'm seeing, after I started an IPA client with a faulty DNS entry in /etc/resolv.conf #8 0x7fda39c9e163 in __gethostbyname_r ( name=name@entry=0x7fff2548d140 client.example.com, resbuf=resbuf@entry=0x7fff2548d120, buffer=0x1f33590 \177, buflen=buflen@entry=992, result=result@entry=0x7fff2548d118, h_errnop=h_errnop@entry=0x7fff2548d10c) at ../nss/getXXbyYY_r.c:266 #9 0x7fda3bb1b3de in ldap_pvt_gethostbyname_a ( name=name@entry=0x7fff2548d140 client.example.com, resbuf=resbuf@entry=0x7fff2548d120, buf=buf@entry=0x7fff2548d110, result=result@entry=0x7fff2548d118, herrno_ptr=herrno_ptr@entry=0x7fff2548d10c) at util-int.c:350 #10 0x7fda3bb1b5d0 in ldap_pvt_get_fqdn (name=0x7fff2548d140 client.example.com, name@entry=0x0) at util-int.c:748 #11 0x7fda3bb19b47 in ldap_int_initialize ( gopts=gopts@entry=0x7fda3bd4 ldap_int_global_options, dbglvl=dbglvl@entry=0x0) at init.c:645 #12 0x7fda3bb1a627 in ldap_set_option (ld=0x0, option=24582, invalue=0x7fff2548d2b0) at options.c:446 #13 0x7fda30951cf6 in setup_tls_config (basic_opts=0x1f30450) at src/providers/ldap/sdap.c:533 #14 0x7fda308214b3 in ldap_id_init_internal (bectx=0x1f12b40, ops=0x1f12cb0, pvt_data=0x7fff2548d5e8) at src/providers/ldap/ldap_init.c:146 #15 0x7fda30821ba0 in sssm_ldap_id_init (bectx=0x1f12b40, ops=0x1f12cb0, pvt_data=0x1f12cb8) at src/providers/ldap/ldap_init.c:199 #16 0x0041b227 in load_backend_module (ctx=0x1f12b40, bet_type=BET_ID, bet_info=0x1f12ca8, default_mod_name=0x0) at src/providers/data_provider_be.c:2346 #17 0x0041ce4c in be_process_init (mem_ctx=0x1f0ba80, be_domain=0x1f093f0 localipaldap, ev=0x1f0a630, cdb=0x1f0bb90) at src/providers/data_provider_be.c:2520 #18 0x0041fde6 in main (argc=3, argv=0x7fff2548e008) at src/providers/data_provider_be.c:2743 Do you agree this is an openldap bug? I don't like that ldap_set_option triggers a blocking DNS resolution call.. Yeah, that's certainly unexpected. Please open an OpenLDAP bug. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOHH40ACgkQeiVVYja6o6OzPgCfd+XTHJ9Y9XsiMXN60gP2ncbK mO8An0VgR8U+Hgj8e02kG9R7CpaUfVEf =y0Qv -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] 1.11.5 ddns failure on Ubuntu 14.04 [SOLVED]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/22/2014 08:55 AM, Rowland Penny wrote: On 22/05/14 13:50, John Hodrien wrote: On Thu, 22 May 2014, Rowland Penny wrote: Not on Ubuntu it isn't ;-) I'd argue that Ubuntu just has incorrect behaviour then. If you look at man hosts on an ubuntu machine (13.10), you'll see how they describe it, and the example they provide. The format described is: IP_address canonical_hostname [aliases...] The example is: 127.0.0.1 localhost 192.168.1.10 foo.mydomain.orgfoo 192.168.1.13 bar.mydomain.orgbar That's the correct format, whether or not Ubuntu applies it. Thats all very well for a machine with a fixed ip but what about DHCP ? Well, once they adopt systemd, they'll get to start using hosts: files dns myhostname This properly populates gethostby*() with the appropriate values from DHCP. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlN99kMACgkQeiVVYja6o6M0RgCgjIrcRxplNbuEP07EPvPy9ucu FF4An1xeW/58DI+8WEG+J9lcrLx7bDEV =4BYY -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] (objectClass=ipService)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/09/2014 07:32 AM, Michael Ströder wrote: HI! How does sssd decide whether to send searches with filter (objectClass=ipService) or not? Does it depend on services: sss set in /etc/nsswitch.conf? Yes, 'service: sss' must be set and some application must call getservbyname() (or related libc calls) to invoke it. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNsw4kACgkQeiVVYja6o6NEjACfePTof6771rWM3LzK4AJ2rqwE HpAAnjDv6F0N5tL0hwofFN1USGbxWGkL =k5Fa -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] (objectClass=ipService)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/09/2014 08:49 AM, Michael Ströder wrote: On Fri, 09 May 2014 07:59:25 -0400 Dmitri Pal d...@redhat.com wrote On 05/09/2014 07:32 AM, Michael Ströder wrote: Does it depend on services: sss set in /etc/nsswitch.conf? Yes Maybe I should clarify that I want to *disable* searches with (objectClass=ipService) sent by sssd. Is it sufficient to just omit sss from line services in nsswitch.conf? Yes, you can remove it from nsswitch.conf and SSSD will no longer be queried. You will want to do a full system reboot after making that change, since running processes don't pick up changes to nsswitch.conf (which includes system services). The easiest way is to just reboot. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNsz5sACgkQeiVVYja6o6N45wCfVE4hKR1LUvgS1vdX4DggGycC u7UAn3/oS5kcqAfzdkJ63duBByMIWjGt =CARB -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] timeout and offline mode behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/17/2014 04:13 AM, Jakub Hrozek wrote: On Wed, Apr 16, 2014 at 10:47:10PM -0400, Simo Sorce wrote: On Wed, 2014-04-16 at 19:49 -0400, Dmitri Pal wrote: I had some interesting experience during Red Hat summit. The network was significantly overloaded. The VPN was slow and probably bleeding packets on the way like crazy. Any access to internal web page took a while and was happening in multiple steps. When screen was locking it was taking about 30 sec (I have not measured but that was a feeling) to log in. I am not sure we can do much about it but the flaky network is probably going to lead to some timeouts and bad user experience. I think this may be a recent regression. We are never supposed to wait more than a handful of seconds, but I am noticing that with latest RHEL6 updates my RHEL desktop also sometimes gets stuck a while on authentication (VPN). I have not experienced this in F20 (but my domain controller is local). Simo, if you can reproduce the error locally, would you mind enabling debug logs or trying out the 6.6 preview packages? I only have headless VMs with RHEL6 and I'm not sure I could reproduce the bug there. But it sounds like something we should fix, so any debug information would be welcome, at least to know where to start with local debugging. btw when I tried to reproduce the bug Thomas was seeing, I saw some blocking DNS calls in openldap's initialization path, but that was on F-20. OpenLDAP isn't supposed to be calling DNS at all. That's the entire reason we open the port ourselves now and then pass the FD to it. If it suddenly started running DNS, that's probably a regression in the openldap libraries. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNVJcYACgkQeiVVYja6o6MgggCdGuaJy1kSizyYzvrmOXMRtjEs XIYAn2dvdRyVVt4+NLStbiHamO1dcpQ7 =oM2L -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] timeout and offline mode behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/02/2014 07:41 AM, Jakub Hrozek wrote: On Wed, Apr 02, 2014 at 12:02:41PM +0300, Thomas B. Rücker wrote: Hi, we're using SSSD in combination with active directory and have received complaints from users about a corner case in our setup. Our AD servers are only reachable from within our corporate network, connection attempts from the outside are dropped by firewalls. This leads to the following scenario: - user takes machine (e.g. laptop) outside the corporate network - user tries to authenticate (or in some cases also tries to ls which causes uid/gid lookup) - sssd will try to reach the configured servers for up to 30s ^^^ This is not so clear to me, are you saying that it takes up to 30 seconds for SSSD to realize it's offline and switch to the offline mode? - sssd goes (back) into offline mode and uses cached credentials and authenticates the user I'm using a very similar setup on my laptop where I authenticate against LDAP and Kerberos servers inside Red Hat's internal network. I see a couple of seconds lag sometimes, but not 30s as you describe.. What he's saying is that the firewall behavior from outside the network is DROP. In our case, the address isn't even resolvable from outside, since we use private DNS entries. So we have a short-circuit. In his situation, the address is resolvable, so SSSD sends a request to connect to LDAP. It then hangs with no response. Now, this *should* be hitting the 6 second ldap_network_timeout default value. I'm not sure why it's not, unless there's a timeout failure happening during connect() instead of during poll/select, which I don't think we can actually avoid. snip Can you enable debugging and see where the biggest lag is? Maybe we could see what exactly takes the longest and lower the appropriate timeout. This would be very helpful. Please set 'debug_level = 7' in the [domain/DOMAINNAME] section of sssd.conf, restart SSSD and then gather the logs. Look at the timestamps to see what is happening for about thirty lines before and after the lag. Ideally, sanitize that log and send it to us. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM8AmEACgkQeiVVYja6o6MrWQCgm1/kOZ5g9sePtV0o+k4Cs7D8 TyIAoIcJDpCmTbLPZGrqW8KebdiGMacz =xKtv -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] SSSD + PAM configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/21/2014 12:40 PM, kevin sullivan wrote: Thanks for the input Dmitri! It is up to you where you draw the line between local accounts and central accounts but moving everything including root seems to me to be too much. I agree that it might be too much, however, it is something that I felt needed investigation. For the record, root (and UID/GID zero) is special-cased in SSSD. You *cannot* log in as root through SSSD. (The reasoning is that if SSSD was broken, you wouldn't be able to get into the system at all to fix it). -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMsk/MACgkQeiVVYja6o6NlBwCfRuoCzMLyHcSj0kUiGmfq8nG7 T3IAnjlNYnV5GP22wBLKjLDw9uidG3e6 =GjkT -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] home directory ownership
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/21/2014 04:46 AM, Sumit Bose wrote: On Thu, Feb 20, 2014 at 10:22:53PM +0100, Jakub Hrozek wrote: On Thu, Feb 20, 2014 at 04:13:51PM -0500, Simo Sorce wrote: On Thu, 2014-02-20 at 16:01 -0500, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/20/2014 03:37 PM, John P Arends wrote: I’m new to SSSD in general. I configured a RHEL 6.5 machines to authenticate against a 2008 R2 AD using ldap_id_mapping because our AD does not have unix information defined for users. All appears to be working well. I had to add override_homedir = /home/%u to get home directories to to be created by oddjob mkhomedir. The only problem is the group ownership on the home directory is “domain users” rather than the user’s private group. The default permissions also allow domain users read/execute access to the home directory. It looks like you can change the umask used in /etc/pam.d/system-auth-ac, but I don’t see where I can control the group information. Any suggestions on best practices on how to fix this? I was surprised it wasn’t in the docs. Domain Users most likely *is* the user's primary group. By default, Active Directory doesn't create user-private groups. If you run 'id username', you should see gid=XXX(domain users) which is telling you what the default group is. You will want to change this on the Active Directory side, or else use a umask on the RHEL system to set the created directories as not readable by the group members. See /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf for details. You can modify the '-u' option to the mkhomedir call to do this. Didn't we discuss a while a go to add a feature to sssd so that it would create local private groups for AD users instead of using 'Domain Users' a the primary gid ? The idea was to painlessly handle exactly these kind of problems. Simo. I vaguely remember discussing something along the lines of it would be nice to do..sometimes.. on one of our weekly meetings but there was never a trac ticket or a design. I guess we have done it the way it currently is to be compatible with other solution, but I think it is a good idea to add an boolean option like ad_use_user_private_groups. John, would you like to file an RFE at https://fedorahosted.org/sssd/ about this? It's worth noting that, because of the way SIDs work in AD, if we're using ID-mapping, it's safe for us to create an MPG with the same GID as the UID, since they will never overlap in AD. However, if we're *not* using ID-mapping, this wouldn't be safe, since the various GIDs on the system are specified manually and could overlap. So I'd make this an ID-mapping only option. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMHSa0ACgkQeiVVYja6o6PN/gCgkD/MQuDht5NNhlV1/pPbFHgR fmAAoIBlrP08o+HesvPxSR777AkgMVtT =FQPB -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
[SSSD-users] Unofficial SSSD 1.9.x repository for RHEL 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Due to popular request, I am offering a completely unofficial and unsupported repository of the latest 1.9.x LTM bits for RHEL 5 and derivatives. The latest official version supported by the distribution is 1.5.x. These packages are built from the upstream sources using the same spec file that was used to generate the nightly builds back when 1.9.x was the master branch, so it's expected to work just fine. You can find the repository and instructions how to use it at: http://copr-fe.cloud.fedoraproject.org/coprs/sgallagh/sssd-1.9-rhel5/ Please do not file bugs against Bugzilla for issues discovered with these builds. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMGAwAACgkQeiVVYja6o6McygCdH6OGn//W3Po7XokoHLEOIzS+ 0VUAoK8mfaLdSzzoLpFZMLd/gFqNf5YY =xEFs -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] home directory ownership
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/20/2014 03:37 PM, John P Arends wrote: I’m new to SSSD in general. I configured a RHEL 6.5 machines to authenticate against a 2008 R2 AD using ldap_id_mapping because our AD does not have unix information defined for users. All appears to be working well. I had to add override_homedir = /home/%u to get home directories to to be created by oddjob mkhomedir. The only problem is the group ownership on the home directory is “domain users” rather than the user’s private group. The default permissions also allow domain users read/execute access to the home directory. It looks like you can change the umask used in /etc/pam.d/system-auth-ac, but I don’t see where I can control the group information. Any suggestions on best practices on how to fix this? I was surprised it wasn’t in the docs. Domain Users most likely *is* the user's primary group. By default, Active Directory doesn't create user-private groups. If you run 'id username', you should see gid=XXX(domain users) which is telling you what the default group is. You will want to change this on the Active Directory side, or else use a umask on the RHEL system to set the created directories as not readable by the group members. See /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf for details. You can modify the '-u' option to the mkhomedir call to do this. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMGbTwACgkQeiVVYja6o6NihwCglFl7evGM60fjcWKIDn7dnwkh VE0AoJ+881ANNEsgwgJvZMGs19O0jR5f =wA9A -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] ldap authentication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/10/2013 10:40 AM, Dan Candea wrote: On 12/10/2013 05:21 PM, Jakub Hrozek wrote: On Tue, Dec 10, 2013 at 04:57:47PM +0200, Dan Candea wrote: On 12/09/2013 07:00 PM, Lukas Slebodnik wrote: I would suggest to configure sssd against AD with relamd. debian = jessie and ubuntu = raring contain this package. http://packages.debian.org/jessie/realmd http://packages.ubuntu.com/raring/realmd LS Thx, this gave me a new config to start-up, and finally it worked. Any workaround until this https://fedorahosted.org/sssd/ticket/1560 is solved? Can you try setting: ldap_user_ssh_public_key = sshPublicKey I have like this [domain/2FA.TEST] ad_server = 2fa-ad.2FA.TEST ad_domain = 2FA.TEST krb5_realm = 2FA.TEST realmd_tags = manages-system joined-with-adcli cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = False fallback_homedir = /home/%d/%u access_provider = ad krb5_use_enterprise_principal = True debug_level = 10 enumerate = False ldap_referrals = False ldap_id_mapping = True min_id = 1000 ad_access_filter = memberOf=CN=Linux-Admins,OU=Security Groups,DC=2FA,DC=TEST ldap_user_search_filer = memberOf=CN=Linux-Admins,OU=Security Groups,DC=2FA,DC=TEST *ldap_user_ssh_public_key = sshPublicKey* but in the sssd_ldap log I can see [sssd[be[2FA.TEST]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sshPublicKey] . [sssd[be[2FA.TEST]]] [sdap_attrs_add_ldap_attr] (0x2000): sshPublicKey is not available for [testuser]. and in the ldapsearch i can see the attribute sshPublicKey: ssh-rsa B. How are you running the ldapsearch? This public key needs to be accessible via the host account on the machine. You can test this with: kinit -k host/f...@2fa.test (substitute the proper hostname for FQDN) And then run 'ldapsearch -Y GSSAPI other arguments' This will simulate the search that SSSD is running. My suspicion is that the ACL on the sshPublicKey attribute is visible to your user account but not to the SSSD host account. This will confirm that. If so, you need to have the AD admin grant access to that attribute for host accounts. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKnOLsACgkQeiVVYja6o6MghgCZAdbld3aZRMYZW5IpNvsXpA4g 0ZYAoKZojyBfuavaI0ejmEC00o5rZhQB =WtFg -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] authconfig and moving from ldap to sssd on redhat6 boxes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/21/2013 11:29 AM, Olivier OLG wrote: Hello there, two observations about using authconfig to switch from ldap to sssd on redhat6 : 1- why does authconfig stops sssd when it's launched with --enablesssd --enablesssdauth flags (rather than restarting the service) ? 2- I also use --disableldap --disableldapauth --enablepamaccess flags and it appears that authconfig has updated properly all files in /etc/pam.d/* except for /etc/pam.d/sudo : # grep ldap /etc/pam.d/sudo authsufficientpam_ldap.so use_first_pass account [default=bad success=ok user_unknown=ignore] pam_ldap.so passwordsufficient pam_ldap.so use_authtok session optional pam_ldap.so Nothing critical in all that (to me at least), since I found workarounds, however may be this should be fixed with next authconfig versions ? While we work closely with authconfig, they are in fact a different upstream. Bugs in authconfig should be reported at https://bugzilla.redhat.com/enter_bug.cgi?product=Fedoracomponent=authconfig -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJmbuQACgkQeiVVYja6o6NocACfbV2aAJ2Mpsu39W7RgVKRN+i9 u4EAoJijBNflnJDEF6LnoD2+9cnUPsmq =0BCc -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] RHEL 6 ldap client can query a group, but cannot traverse groups of groups.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/22/2013 12:13 PM, ted.r...@faa.gov wrote: Hi! We have been working this problem for two weeks debugging. We have 389-ds running and multi-master with 3 RHEL6 servers and a RHEL5. The RHEL5 ldap clients authenticate correctly to the RHEL6 389-ds directory server and with 'id' command can see all groups a user belongs too. The same command in a RHEL6 ldap client using sssd shows ONLY the primary group. If we change the ldap clients to point at the RHEL5 389-ds directory server the same results occur. The one consistency is any RHEL6 ldap client we setup will authenticate to either RHEL5 or RHEL6 but the entire list of groups that user belongs to do not transfer independent of server version. We have enumerate set to true and we have ldap_group_member set to uniqueMember. These seems to point to the ldap client as RHEL5 client works just fine and both RHEL5 and RHEL6 389-ds servers react the same but we're not sure how to correct or is it a bug. HELP? We had this posted in 389-users but were referred to the sssd list. id of a user(id JSmith) only returns the primary group, not a complete list of the groups that user belongs too. The getent group MyGroup lists the subgroups by names but not the members. On a RHEL5 ldap client the same entries provide a complete list of groups the user belongs to when entering id JSmith. The getent group MyGroup also burrows down through subgroups to list all users that belong to that group either directly or because a group they belong to belongs to the group MyGroup. Any ideas? The problem seems to be with RHEL 6 ldap client and some settings in sssd but not sure where to go from here. I suspect that things will work properly if you set ldap_schema = rfc2307bis in the [domain/DOMAINNAME] section of /etc/sssd/sssd.conf and run 'service sssd restart' For other things to try, check out https://fedorahosted.org/sssd/wiki/FAQ#CommonIssues If none of those suggestions work, please follow the tips on https://fedorahosted.org/sssd/wiki/Troubleshooting for reporting an issue. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJmr28ACgkQeiVVYja6o6MBZACfSx0xOGGbxlRjnC0nIziJOqwv LPkAnA22V4M7fjGCm6VE2NZeaZS8Djab =z4wN -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] ldap_group_search_base filtering
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/2013 12:45 PM, Bright, Daniel wrote: Well It looks like I’ve answered my own question with some trial and error, I replaced the nss stuff that I had in ldap.conf with this: ldap_group_search_base = ou=Groups,dc=some,dc=company,dc=com?sub?(|(host=\2A)(host=somehost.test.com)(host=test)) Maybe I'm parsing this wrong, but isn't this filter saying Any record with a host entry, or any record with one of two specific host entries?. It looks to me like (host=somehost.test.com)(host=test) is redundant. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJdes8ACgkQeiVVYja6o6Pr4gCgrfClB89WEBbJsIb3p0I3YG90 cIMAn08A9wMFqu8LvhthT1O0cWGQmBUO =Pkaj -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Dynamic DNS update with AD backend using wrong hostname for nsupdate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/14/2013 12:55 PM, Chris Hartman wrote: Maybe try to use the dyndns_iface option This forced an IPv6 record update :) How come this wasn't done automatically, though? While entirely possible, it's a bit of a pain to set the interface for all hosts, especially because there is no guarantee that it will be the same interface for every host. If I could get around setting this explicitly, that would be a better option. It's very difficult to determine exactly which interface is the public one. When we don't have the dyndns_iface option specified, our default behavior is to assume that the IP address we are using to connect to LDAP is the public one. Probably would be a good RFE to make sure it updates DNS with any and all IP addresses assigned to that interface though, rather than simply the one that's actually connected to LDAP. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJcJFQACgkQeiVVYja6o6MMfgCfcjB8Zb6Igbv2819jRd/MtlwY 4gQAn3NtPnv30Q2ZIt4ndmQvn+aE6A05 =j+UN -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] sssd.conf, authconfig and ldap_uri
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/11/2013 08:07 AM, Olivier wrote: Hello Stephen, this is done : https://bugzilla.redhat.com/show_bug.cgi?id=1018189 I have reported it as an authconfig bug, I think it might also be something to be considered at sssd level : should'nt sssd use dns_discovery_domain to look for ldap server rather than ldap_uri if borth parameters are declared in sssd.conf ? No, because they're not directly related. You could be using DNS discovery only for Kerberos (for example). The idea is that if you have ldap_uri specified, you're doing it intentionally to override DNS. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJX7VAACgkQeiVVYja6o6Mw7QCdG/QZW/J+s3MS9UOyYo7A1sGH q1IAoIxlfr/0WOnQLdgYgx7maBKSnjWd =i0p+ -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Home Directory not being created
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/09/2013 12:20 PM, Chris Hartman wrote: Well, in a related development, it appears there is a hardware issue with the testing PC- bad hard disk. Will replace, reinstall OS, and re-test. However, there is definitely a case sensitivity issue happening. My other hosts only have an issue when logging in with Guest as opposed to guest. Guest causes /home/guest to be created despite what's in the unixHomeDirectory attribute; then I'm always dropped in / because Could not chdir to home directory /tmp/Guest: No such file or directory. I imagine this because sssd is lowercasing usernames but PAM isn't? getent passwd guest always returns the same result: guest:*:1596000501:1596000514:Guest:/tmp/Guest:/bin/bash Hmm, maybe I misunderstood something here. I just re-read in your original mail that this home directory was specified in LDAP, not as part of the fallback_homedir processing. So that makes sense for why it's leaving it capitalized; we always take that string from LDAP literally, regardless of case-sensitive operation. So if that's the case, I'm somewhat at a loss for why it would be creating /home/guest at all (instead of what's in the passwd entry, which is /tmp/Guest and is therefore the directory that the shell tries to use). Can you show me *exactly* what 'getent passwd Guest' returns and then also what 'getent passwd guest' shows on the same system? They are *supposed* to have identical output, whatever that output ends up being. However, I suspect that this is going wrong somewhere. I really need to see those two outputs side-by-side, please. If I login in with guest, everything works as expected (after the cache is cleared). It seems strange that I'm even allowed to auth with both guest and Guest. Shouldn't one fail? Is this a bug or feature? When you log in as 'guest', what is the output of echo $HOME? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJX8OcACgkQeiVVYja6o6MOEACeL479v5eLIcWM40ksjU80aMuI uOIAoKIQtkz/XEMP5i53X1injirir/lX =bZJh -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] sssd.conf, authconfig and ldap_uri
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/11/2013 08:41 AM, Olivier wrote: Hello Mikael, I don't know if sssd.conf support this syntax, nor authconfig, but that would not work for me anyway. authconfig generates other configurations than sssd.conf such as pam_ldap.conf for example (which does not support dns discovery). That's why I need to launch authconfig with explicit ldap servers (and I don't want them to be declared in ldap_uri). Why are you configuring pam_ldap if you're using SSSD? That doesn't make any sense. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJX9lkACgkQeiVVYja6o6MK+ACeKqoFBNgp85yorZ1TnP2R6+1c 870An1EBiYZbfpowfFKTvkyaDY3H1xR4 =mg52 -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] lines beginning with spaces in sssd.conf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/09/2013 01:22 PM, Dmitri Pal wrote: On 10/09/2013 01:05 PM, Ondrej Valousek wrote: Hi List, I have noticed that since F19 I can not use lines beginning with spaces in sssd.conf - sssd complains otherwise. Was this an intentional change? I used spaces/white characters to ident the config for better readability. Thanks, Ondrej ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users There was a change in the underlying libini_config library to treat spaces as wrappers by default. Just to clarify what this means: libini_config changed its behavior so that a leading space should be interpreted as a line-continuation from the previous line. So if you had REALLY long data (such as a complex ldap_search_filter), you could make it more readable by spreading it out on multiple lines. It is probably a bug in the SSSD implementation of libini_config Hm... yes. Line 225 in https://git.fedorahosted.org/cgit/sssd.git/tree/src/util/sss_ini.c s/0/INI_PARSE_NOWRAP You can definitely file a ticket for that. Feel free to file a ticket, but I think the wrapping behavior may prove more useful. Hard to say. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJVmlQACgkQeiVVYja6o6PCyACfZrc8TlFM2mRdWQloSXTScWgR 2o4AnAx+Wh4ok21IlurhmDJM1FvaZIaB =M0wB -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Home Directory not being created
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/09/2013 01:06 PM, Chris Hartman wrote: Could you file a bug against pam_mkhomedir? I can definitely do this, though I'm not exactly sure what the bug is because I don't think I understand the problem fully. mkhomedir.so doesn't play nice with aliased usernames? Can you offer a little more guidance and/or explanation? Basically, when pam_mkhomedir.so is invoked, it has a substitution template that it fills in with the username. Apparently, it is taking the input value from PAM as this substitution value, but if you happen to be logging in the first time from an alias (anything other than the canonical version, which is the lower-case one in this example), it creates the directory with that instead of the canonical one. When running id_provider = ad, we default to operating in case-insensitive mode. Is there a config option that exposes case sensitivity mode? If not, such a feature might be useful. Not sure if that is programmatically feasible/practical, though. - From the AD provider manpage (http://jhrozek.fedorapeople.org/sssd/1.11.1/man/sssd-ad.5.html): Users, groups and other entities served by SSSD are always treated as case-insensitive in the AD provider for compatibility with Active Directory's LDAP implementation. - From the sssd.conf manpage (http://jhrozek.fedorapeople.org/sssd/1.11.1/man/sssd.conf.5.html): case_sensitive (boolean) Treat user and group names as case sensitive. At the moment, this option is not supported in the local provider. Default: True Essentially, using 'id_provider = ad' implies 'case_sensitive = False' -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJVmbIACgkQeiVVYja6o6PUQgCfU5J5mg7Q/XpZQ8Dwdv+ORjKa VZsAnjXosUGYG28bQmnTl+XwDkU5Mjx8 =ufaB -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] [SSSD] FreeIPA on Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/01/2013 04:35 PM, Timo Aaltonen wrote: On 01.09.2013 21:43, Dmitri Pal wrote: On 09/01/2013 02:20 PM, Timo Aaltonen wrote: - dyndb support in bind * haven't asked the maintainer to add it to bind9, it might happen Are you talking about byndb maintainer or bind9 Debian maintainer? May be we should connect the two? the debian bind maintainer, I heard from the dyndb maintainer that bind10 might support it natively, but getting that in Debian might still be further in the future, so if we'd need dyndb by early next year it's probably needed to have it via bind9 first. FreeIPA ships a separate package, bind-dyndb-ldap as an add-on for bind 9. You should be able to do the same in Debian. We should connect the bind-dyndb-ldap upstream with you so we can figure out if that will work. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIlzOMACgkQeiVVYja6o6NIhQCfXX68m4X/4nkdIG6OEdKLfYPX j+0AnArkaxKO1Ym+Z/FZvuHli8WfAcdH =TKLC -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] ssh (sssd) ldap authentication problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/21/2013 01:58 PM, John Uhlig wrote: oops! please excuse previous reply re: SHA1. John. It would be very helpful if you could include your sssd.conf. I strongly suspect that you have a typo in your configuration somewhere. I have included sssd.conf file. I have tried to keep it as simple as possible but have tried several iterations on it as well. - [domain/default] debug_level = 9 ldap_id_use_start_tls = True ldap_search_base = ou=internal,dc=parc,dc=com krb5_realm = EXAMPLE.COM krb5_server = kerberos.example.com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldap://pldap.parc.com/ cache_credentials = True ldap_tls_cacertdir = /etc/openldap/cacerts ldap_tls_reqcert = demand [sssd] services = nss, pam config_file_version = 2 enumerate = True domains = default [nss] [pam] [sudo] [autofs] [ssh] [pac] I have to ask the obvious question: does it work if you set 'ldap_tls_reqcert = allow'? This could suggest that your /etc/openldap/cacerts directory isn't properly set up. You may have forgotten to run 'cacertdir_rehash /etc/openldap/cacerts' or to put the CA cert in that directory at all. I'd like to see more of the SSSD logs than just (Wed Aug 21 08:27:45 2013) [sssd[be[default]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! because that's not a useful piece of the log (it doesn't tell me what it tried to do before it failed). Including the preceding 50-100 lines would be better. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIVAGEACgkQeiVVYja6o6PTFwCgnDMBDlnP/1ZrJ1C8+of1uJVV r7sAn3l0zVm6Qd5E1+PgmZy9A3WyERE5 =44TE -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Use of TLS security certificates in sssd for ldap authentication ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/01/2013 02:13 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: I have been testing different configurations of sssd and RHEL V6.3 and V6.4. The sssd version on RHEL V6.3 is sssd-1.8.0-32.el6.x86_64 The sssd version on RHEL V6.4 is sssd-1.9.2-82.el6.x86_64 Recently in reviewing my configuration and comparing same to a customers sssd.conf I noticed that I was not able to authenticate ldap users on the RHEL V6.3 system without some reference to a TLS security certificate. More to the point, you must point specifically at the certificate itself and not just the directory in which the certificate can be found: # This doesn't seem to work in RHEL V6.3 #ldap_tls_cacertdir = /etc/openldap/osncerts If this isn't working, check to make sure that you have run 'cacertdir_rehash' on that directory. I suspect you have not (and thus it won't work with the cacertdir option). # This line seems to be required for RHEL v6.3 ldap_tls_cacert = /etc/openldap/osncerts/server.pem Specifying it directly avoids the need for properly hashing the certificates. If this line is commented or is not in the sssd.conf, authentication fails and I see this error in the /var/log/messages file: Could not start TLS encryption. TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. I also see that no reference what so ever to the TLS certificate is required in RHEL V6.4 running the later version of sssd. Check where your certificates are. I suspect they're in either the default location (/etc/openldap/cacerts) or that /etc/openldap/ldap.conf has the cacertdir option pointing to it for you (and the directory is properly hashed). In that case, SSSD will just pick up these values and use them without you needing to do anything. Alternately, do you have 'ldap_tls_reqcert = allow' (or none) set in your config (either in sssd.conf or ldap.conf)? This bypasses the security check. Can anyone explain this ? Are there any plans to require a security certificate in sssd when using ldap for authentication ? Not so much plans as a mandate. We don't allow using LDAP for auth over an insecure tunnel EVER. If you try to perform a bind and SSSD sees that the channel isn't secure, it will just immediately return failure instead of attempting the auth. This is because the LDAP protocol sends the password in plaintext, so we don't allow this to happen unless the channel itself is encrypted. Are there any plans to force encrypted communicates in sssd when using ldap for authentication ? We already do. You are almost certainly using it without realizing. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlH6qXEACgkQeiVVYja6o6PIUQCdG0KUk7/xXjh4810dhiwOpGb+ v/MAoLAdSFjaQVi31j+1gviEdsYlQVTm =xH2T -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Problem with sssd and udev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/20/2013 02:20 PM, Dmitri Pal wrote: On 05/20/2013 02:15 PM, Stephen Gallagher wrote: On 05/20/2013 12:50 PM, John Bossert wrote: 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. Could you try pulling down the version of SSSD that was released in RHEL 6.2 (it should be SSSD 1.9.2). This may fix your issue. Did you mean 6.4? Yes, I meant 6.4. Sorry for the embarrassing typo. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGaalgACgkQeiVVYja6o6PNswCgjjOzpQd91XuaPE0PzzOO1NLu 6ZIAnjI1AA7prxY/98k2mDzCSQo4F7er =MXPD -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Nested Groups in ldap_access_filter?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/09/2013 09:58 AM, Wojtak, Greg (Superfly) wrote: Thanks for the help. Would a similar solution be to set the ldap_access_filter to ((cn=unix team,Š)(cn=server1access,...)) with the server1access group containing the member's dn's? The reason I ask this is so that we can avoid having to assign gidnumbers to these groups? This won't work because the user will only have one or the other memberOf attribute. You *could* do: ldap_access_filter(|(memberOf=cn=unix time...)(memberOf=cn=server1access...)) (note the OR there). But the problem with this is that you will need to update your client configuration manually any time a new group is added to the nesting. That's why I'd recommend just assigning POSIX attributes and using the simple access provider. Also, feel free to open an RFE to request a nested-non-POSIX access provider extension for LDAP in our bug tracker at https://fedorahosted.org/sssd You're not the first person to ask for it, but it's trickier than you might expect to get it right. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGLrjgACgkQeiVVYja6o6MRqACgiIhdn+/bJVTGswLFU+gznsUE BPYAoJ8q0ACOair18Eof2ICPdEb+TdHF =w7NP -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] ldap config
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu 25 Apr 2013 02:02:56 PM EDT, Brandon Foster wrote: On Wed, Apr 24, 2013 at 11:20 AM, Stephen Gallagher sgall...@redhat.com wrote: * *BEGIN ENCRYPTED or SIGNED PART* * On Wed 24 Apr 2013 02:15:51 PM EDT, Brandon Foster wrote: forgot to attach *facepalm Ah, sorry. I forgot to tell you to set 'timeout = 5400' in the [domain/DOMAINNAME] section of sssd.conf. By default, the SSSD will forcibly kill off the unresponsive sssd_be process after 30s (which makes debugging hard). This gives you 90 minutes to get the results. That should report a backtrace now. ** *END ENCRYPTED or SIGNED PART* ** Attached is my output from gdb. not sure if its what you are looking for. This looks like you started SSSD and then shut it down without trying to log in in the middle. Did you leave that part out? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEUEARECAAYFAlF5fWUACgkQeiVVYja6o6PVwwCSAhMH3YvNl7dhv9CtSNg/PYdQ 9gCcDkVQb+e/v+1NsSXVl7BwDm6xzFw= =VFzo -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] ldap config
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/24/2013 12:49 PM, Brandon Foster wrote: On Tue, Apr 23, 2013 at 12:20 PM, Stephen Gallagher sgall...@redhat.com wrote: ... Would you mind trying out the SSSD from CentOS 6.4 to see if this particular crash has already been fixed there? If not, please try to get a backtrace (of the 6.4 version of SSSD) with GDB. You will need to take the following steps: yum install gdb debuginfo-install sssd gdb -p $(pidof sssd_be) ... Missing separate debuginfos, use: debuginfo-install sssd-1.9.2-82.4.el6_4.x86_64 Spot the mistake? :) Please run the debuginfo-install command above. Otherwise, the backtrace output is not human-readable. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlF4DhcACgkQeiVVYja6o6OGwgCgmPZ6fXHA30fEPNzZXvViuUPv ZekAn2RxpJQiwvPB6/pK48eKasSGMge3 =Dzyo -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] ldap config
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue 23 Apr 2013 12:55:19 PM EDT, Brandon Foster wrote: hey all, Im new to sssd and ldap so be gentle =) I've followed some guides on how to set up sssd ldap client authentication on Centos 6.3 but mine doesnt seem to be working here is my sssd.conf - [sssd] config_file_version = 2 services = nss, pam domains = default [nss] filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd [pam] [domain/default] auth_provider = ldap debug_level = 9 enumerate = True cache_credentials = True chpass_provider = ldap entry_cache_timeout = 600 krb5_realm = EXAMPLE.COM krb5_server = kerberos.example.com ldap_chpass_uri = ldaps://xx.xx.xx.xx:PORT/ ldap_force_upper_case_realm = True id_provider = ldap ldap_group_member = uniquemember ldap_group_object_class = group ldap_id_use_start_tls = False ldap_pwd_policy = none ldap_search_base = ou=organizationunit3,ou=organizationunit2,ou=organizationunit1,o=example ldap_schema = rfc2307bis ldap_tls_cacertdir = /etc/openldap/cacerts ldap_tls_reqcert = never ldap_uri = ldaps://xx.xx.xx.xx:PORT/ ldap_user_gecos = displayName ldap_user_home_directory = unixHomeDirectory ldap_user_name = cn ldap_user_object_class = user -- ldapsearcg -z 'cn=username' comes back with all the information about the user but id username takes a really long time and then returns no such user. here is a piece of the log: ... (Tue Apr 23 12:51:29 2013) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [defaultNamingContext] (Tue Apr 23 12:51:29 2013) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] (Tue Apr 23 12:51:29 2013) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [highestCommittedUSN] --- To me it looks like its searching but not finding for some reason any help would be much appreciated. You truncated the log too early. It is only showing the connection to the LDAP server (and the determination of server capabilities). Please include the actual user search that should follow that. I'm guessing your user might be missing something important, like uidNumber or gidNumber (or it's stored in a non-standard attribute name). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlF2vhMACgkQeiVVYja6o6MhFwCgq5BD+hVyPfOiTZxCJ/Hyw79U OaAAnjc9WncvDw+IofzaQUTQgtlGZcVS =VeAV -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Cannot convert objectsid to UNIX ID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/16/2013 12:27 PM, Russell Jones wrote: Hi all, SSSD 1.9.2 on CentOS 6. I am attempting to configure SSSD to authenticate against AD via LDAP. When starting the daemon though, the logs get filled with failure messages about being unable to convert the SID properly for every user. The extra strange part is the SID it says it cannot convert is the same for every user. Example: (Mon Apr 15 15:52:47 2013) [sssd[be[LDAP]]] [sdap_save_user] (0x1000): Mapping user [REDACTED] objectSID to unix ID (Mon Apr 15 15:52:47 2013) [sssd[be[LDAP]]] [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID [S-1-5-21-3220130920-4012199101-135577023-1153286127] to a UNIX ID (Mon Apr 15 15:52:47 2013) [sssd[be[LDAP]]] [sdap_save_user] (0x0040): Failed to save user [REDACTED] (Mon Apr 15 15:52:47 2013) [sssd[be[LDAP]]] [sdap_save_users] (0x0040): Failed to store user 988. Ignoring. Looking at that SID, the RID portion of it is is *really* large. The last section there is 1153286127 (split up, that's 1,153,286,127). Given that you've set an ldap_idmap_range_max of 1,000,000, this pretty much explains why you can't convert this user. The conversion of this should be 1153286127+10 (your ldap_idmap_range_min is the base, which leaves it at 1,153,386,127, which is FAR above the 1,000,000 you have allocated. I'm at a loss to explain why some of your users have IDs in the billion-RID range, but if you want these to be handled properly, I think you're going to need to set the following values: ldap_idmap_range_min = 10 ldap_idmap_range_max = 200010 ldap_idmap_range_size = 20 This will allow you to convert all entries in this domain. However, because it requires reserving all 2 billion possible IDs for one domain, you won't be able to handle a multi-domain forest. I'd contact your Microsoft representatives to figure out why you have entries with such high RID values. Where can I get more information on why it's failing? The following is my sssd.conf: [sssd] domains = LDAP services = nss, pam config_file_version = 2 ;debug_level = 0x1310 [nss] filter_groups = root filter_users = root [pam] [domain/LDAP] ldap_id_use_start_tls = True id_provider = ldap chpass_provider = ldap ldap_uri = ldap://REDACTED ldap_search_base = REDACTED auth_provider = ldap cache_credentials = true ldap_schema = ad enumerate = True ldap_id_mapping = True ldap_user_objectsid = objectSid ldap_idmap_range_min = 10 ldap_idmap_range_max = 100 ldap_default_bind_dn = REDACTED ldap_default_authtok_type = password ldap_default_authtok = REDACTED ldap_tls_cacertdir = /etc/sssd/cacerts debug_level = 9 ldap_force_upper_case_realm = True Also, here's what ObjectSID looks like from LDAP (via ldapsearch) for one of the users it's complaining about: objectSid:: AQUAAAUVaEzvv71MJe+/vRQI77+9RE1a77+977+9AAA= Be aware, this is a base-64 conversion of a raw proprietary value. What you see in the SSSD logs are the results of converting that into the human-readable SID format. Attempting to compare this value directly to any other SID value will provide you very little information. You need to look at the decoded version (the S-1-5-21-* representation). When comparing this to the other user's not being mapped, the objectSid coming from LDAP, at initial glance, is not the same. Could you elaborate on this? Can you show me some examples of objectSIDs that *do* work and several that do not as well? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFtmyIACgkQeiVVYja6o6P73QCdF++U8ybyRrNFJ0M8ObntiMIj q2cAoJQ1bVa0QYxi+uCis6o2mCR5hOad =2MKZ -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Cannot convert objectsid to UNIX ID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/16/2013 07:15 PM, Russell Jones wrote: On 4/16/2013 1:40 PM, Stephen Gallagher wrote: Looking at that SID, the RID portion of it is is *really* large. The last section there is 1153286127 (split up, that's 1,153,286,127). Given that you've set an ldap_idmap_range_max of 1,000,000, this pretty much explains why you can't convert this user. The conversion of this should be 1153286127+10 (your ldap_idmap_range_min is the base, which leaves it at 1,153,386,127, which is FAR above the 1,000,000 you have allocated. I'm at a loss to explain why some of your users have IDs in the billion-RID range, but if you want these to be handled properly, I think you're going to need to set the following values: ldap_idmap_range_min = 10 ldap_idmap_range_max = 200010 ldap_idmap_range_size = 20 This will allow you to convert all entries in this domain. However, because it requires reserving all 2 billion possible IDs for one domain, you won't be able to handle a multi-domain forest. I'd contact your Microsoft representatives to figure out why you have entries with such high RID values. Thank Stephen, I've resolved the issue with that - the original server I was querying was returning bad SID data. On another note, I'm slightly confused reading the man page on how slices get assigned and used, and would like to understand it further. For example, here's a clean start for SSSD, with enumeration disabled, and the caches cleared. In other words, brand new: (Tue Apr 16 15:49:51 2013) [sssd[be[LDAP]]] [sdap_idmap_add_domain] (0x0100): Adding domain [S-1-5-21-1289899112-135578405-1515013291] as slice [20] (Tue Apr 16 15:49:52 2013) [sssd[be[LDAP]]] [sdap_idmap_add_domain] (0x0100): Adding domain [S-1-5-21-241006572-1396723338-2091147243] as slice [8] When doing an ID on a user, the number that gets prepended to their userid is not the slice numbers being shown above. It appears to be 41 in this instance: [root@server db]# id USER uid=4165522(USER) gid=4100513 The 65522 remains the same no matter how I edit the idmap_range_max, but the numbers before them (41) change. What do the slice numbers up above, and the 41 here, represent? Thanks for your help! In the default configuration of SSSD, we create 10,000 slices, each capable of handling up to 200,000 IDs. When we see a new user/group objectSID, we parse it into two pieces; the first seven components of data in the objectSID (S-1-5-21-1289899112-135578405-1515013291) identifies the domain that the user belongs to. What we do is take this value and pass it through a hashing function. This hashing function will give us a predictable slice ID, one of the 10,000 slices we created at startup. This slice ID defines the base value for UIDs/GIDs in that domain. So if your domain hashes to slice 20, in the default configuration this means that the base ID value would be (200,000 + 20*200,000) (ldap_idmap_range_min plus twenty times the ldap_idmap_range_size value). or: 420 I'm guessing that you modified the idmap_range_min to be 10 instead of the default 20 (like I had originally recommended), and that's why your range was starting at 410 Once we have the base ID value identified by the hashing algorithm, we look at the remaining part of the objectSID, which is called the RID (relative ID). We take this number and just use it as an offset from the base ID value. So the end result is base_value + RID. When you tweak the size of the idmap_range_*, it alters the total number of slices that are available to the configuration, which means that the hashing algorithm will end up returning a different slice value. (In technical terms, after we hash the domain SID, we take its modulus with the total available slices in order to figure out which slice to assign it). I hope this has been informative. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFuJ6AACgkQeiVVYja6o6MJVwCgkMr8RwYUrebReBeXHqzFNZ6H IqQAn3N/fHCR6qB7zxXyawDdJ9lM9e1L =6aE+ -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] How to restrict users by GID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/12/2013 08:26 AM, Licause, Al (BCS) wrote: The following entry into an ldap.conf file on a RHEL V5 system provides for the ability to limit users based in their GID values: nss_base_passwd OU=ldap,DC=mydomain,DC=net?one?|(gidNumber=11001) (gidNumber=11003) Only those users with GID’s of 11001 or 11003 can login. All others are prohibited. I’ve tried the same filter in sssd.conf on a v6 RHEL system but can’t seem to get it to work. It doesn’t cause any syntax errors but it is ignored. I’ve also tried placing an “=” sign after the nss_base_passwd string and quoting everything after the “=” sign….to no avail. Can anyone explain the sssd syntax for accomplishing this task ? There are two ways to accomplish what you're asking, depending on what you really mean: The way that behaved in nss_ldap was that only users whose primaryGID was wither 11001 or 11003 would be *visible* to the system. That means that any other user would not appear with 'getent passwd username' if they didn't have the right primary GID. This can be done in sssd with the ldap_user_search_base option: ldap_user_search_base = OU=ldap,DC=mydomain,DC=net?one?(|(gidNumber=11001) (gidNumber=11003)) However, if you want all users to be viewable with 'getent passwd username' but only some users able to log in, you want to do this instead: ldap_user_search_base = OU=ldap,DC=mydomain,DC=net?one? access_provider = ldap ldap_access_order = filter ldap_access_filter = (|(gidNumber=11001) (gidNumber=11003)) This will allow the system to see all users, but only permit those with that primary GID to actually log in. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFoAhIACgkQeiVVYja6o6MBrQCfehTUMu0LJjX18VNLuykL0sMC KgMAni0xMfrKcpJFpPLgmQ5XXi6AVT1Q =ZOIw -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Offline log in
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/11/2013 08:15 AM, Sutton, Harry (GSSE) wrote: After getting sssd logins working yesterday (thanks again, Sumit), I was pleasantly surprised to find I was able to login this morning with my domain credentials from home /before/ I had established my VPN connection to the office. (I know I shouldn't have necessarily been surprised, that's the expected behavior, but I've been fiddling with this for weeks and only yesterday finally got things working as 'expected'.) Before I made my VPN connection, I did a klist to see the cached credentials, and did a double-take when I saw the TGT: At first I thought I was back in the U.S. Navy boot camp (which is where I was on December 31, 1969) but then I decided this timestamp might have been chosen intentionally to pre-date UNIX epoch time. But why go to all that trouble rather than just use the valid TGT I had received yesterday when I made a live, valid connection? Wasn't that cached, along with my authentication credentials? Our default behavior on modern systems is actually to store the kerberos credential cache in volatile storage (a tmpfs on Fedora). This is intentional as a security precaution, as it means that on reboot you need to have human intervention in order to gain network access again. This can be changed in sssd.conf by setting the krb5_ccachedir option to point to somewhere persistent. We create that special cache file in order to play better with other kerberos-enabled applications (such as krb5-auth-dialog) which would otherwise try to create their own cache in a location that SSSD couldn't be aware of. So we generate a cache file, populate it with intentionally expired data and then establish the user's session with the KRB5CCNAME environment variable set to point to it for the benefit of those other kerberized apps. Once I established my tunnel connection, I checked again, saw the same (old) TGT, so I logged out of the session (without dropping the tunnel connection) and when I logged back in I had a TGT dated today. I'm guessing (something I can test easily enough) that if I had waiting long enough before logging out and back in again, the TGT would have been re-issued correctly. If this is a single-user machine, we recommend enabling the (disabled-by-default) option krb5_store_password_if_offline (set it to True). What this does is temporarily store your plaintext password in the kernel keyring until SSSD detects that it has gone online. This may take as much as two minutes on some systems (though it may be close to instantaneous when using VPN, as we monitor for changes in the network and DNS resolver state as a cue to try reconnecting to LDAP). Then the SSSD will kinit on your behalf and update that stale cache. Also, locking your screen and unlocking it with your password is a less-invasive way to force a kinit as well, rather than logging out and back in. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFmr0oACgkQeiVVYja6o6NDaACfd1xBcHZnvuxhR4QlN5ZBUBVC 01YAoKiOvKy995xWBY6opqCuC0dz7HN0 =tn+V -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Local account logins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/11/2013 09:03 AM, Sutton, Harry (GSSE) wrote: On 04/11/2013 08:44 AM, Stephen Gallagher wrote: Also, try the following experiment: time id -G localuser and show me the output. On the Fedora laptop: real0m58.014s user 0m0.001s sys 0m0.007s On the RHEL workstation: real0m58.012s user0m0.001s sys 0m0.001s Ok, that definitely is showing where the problem lies. This strongly suggests to me that you have a user in your LDAP with the same name as on your local system. What's most likely happening is that the initgroups() call internally is walking through and processing all of the potential groups that username belongs to. Can you check whether getent -s sss passwd localuser Returns anything? If it does, you have an overlap and should probably resolve it on one side or the other. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFmtjYACgkQeiVVYja6o6Ng4ACgr/s1SoT0o3g2DhMJhKtPCI1A xWQAnjSVCcBdbJBfOD3U8A0OgE8/Hlad =WbvW -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] AD authentication failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/10/2013 11:04 AM, Sutton, Harry (GSSE) wrote: Okay, I'm seeing something in my logs that points to why I'm not authenticating with pam_sss.so, and it may be unique to our environment here at HP, although I suspect others will eventually have the same situation. The issue, I think, is that we use email addresses as part of our uid (and dn) attributes, and the '@' sign is getting interpreted as part of a Kerberos realm identifier. In /var/log/secure, for example, I'm seeing login: pam_sss(login:auth): system info: [Cannot resolve servers for KDC in realm HP.COM] , while in /var/log/sssd/krb5_child.log for the same timestamp there's [[sssd[krb5_child[16801 [get_and_save_tgt] (0x0020): 977: [-1765328164][Cannot resolve servers for KDC in realm HP.COM], while /var/log/sssd/ldap_child.log shows the correct realm, [[sssd[ldap_child[16791 [unpack_buffer] (0x1000): got realm_str: AMERICAS.CPQCORP.NET from the /etc/krb5.keytab file. So: is there something in pam_sss.so that needs to be 'fixed' to get around this problem? You can change the domain delimiter in SSSD with the re_expression option in the [sssd] section. By default it assumes user@DOMAIN, but you can swap it out for something else. See the sssd.conf(5) manpage and search on 're_expression'. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFlgUkACgkQeiVVYja6o6PomwCeJLoFKRVgZh7QKJdwxRJIEk6b jXUAoIKooBrskgKtN0ifdHhtXAm2N/G6 =RpR7 -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] AD authentication failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed 10 Apr 2013 01:04:03 PM EDT, Sutton, Harry (GSSE) wrote: On 04/10/2013 11:12 AM, Stephen Gallagher wrote: You can change the domain delimiter in SSSD with the re_expression option in the [sssd] section. By default it assumes user@DOMAIN, but you can swap it out for something else. See the sssd.conf(5) manpage and search on 're_expression'. Okay, I think I still have the problem, in that the delimiter in both instances is the '@' sign. Even when I manually specify the domain portion (e.g., re_expression = (?Pname[^@]+)@AMERICAS.CPQCORP.NET) it continues to flag [Cannot resolve servers for KDC in realm HP.COM] in /var/log/secure. And although ldap_child.log references the correct domain (via the keytab file), krb5_child.log continues to show Attempting kinit for realm [HP.COM]. I'm probably either missing the point of your suggestion, Stephen, or (just as likely) exposing my limited knowledge of regular expressions. Yes, the regular expression syntax is complex. I'm not certain I understand all of the intricacies myself. I'm CCing Jakub Hrozek who can probably help more. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFlncYACgkQeiVVYja6o6P3GgCeIKwB2ItBX61Wt1pscYSEOxrQ +psAoJXJe5mmKzysulzDZ6V1Ug0xZ/LW =iNsL -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] RHEL5-builds of sssd 1.9.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu 28 Mar 2013 10:01:43 AM EDT, Michael Ströder wrote: Ok, now I'm stuck with this output of OpenLDAP lib checks when running 1.9.4's configure: checking for LDAPDerefRes... no configure: error: The OpenLDAP version found does not contain the required type LDAPDerefRes I guess this is because the OpenLDAP 2.3.43 libs that come with RHEL5 does not contain support for the experimental deref LDAP control. Since I don't need it my question is: Any chance to disable this when running configure? RHEL 5.6 and later have an openldap24-libs-devel package that you can build against. You need to install it and then patch the sources with http://paste.fedoraproject.org/6249/79475136/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFUTi8ACgkQeiVVYja6o6MXQQCfYbfP/9b9eMdFt/Xbuyf956uE +0wAnAoKSvO67LzAGEOv6MhKUYh71cOO =h9qa -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] RHEL5-builds of sssd 1.9.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu 28 Mar 2013 10:15:10 AM EDT, Michael Ströder wrote: On Thu, 28 Mar 2013 10:05:35 -0400 Stephen Gallagher sgall...@redhat.com wrote -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu 28 Mar 2013 10:01:43 AM EDT, Michael Ströder wrote: Ok, now I'm stuck with this output of OpenLDAP lib checks when running 1.9.4's configure: checking for LDAPDerefRes... no configure: error: The OpenLDAP version found does not contain the required type LDAPDerefRes I guess this is because the OpenLDAP 2.3.43 libs that come with RHEL5 does not contain support for the experimental deref LDAP control. Since I don't need it my question is: Any chance to disable this when running configure? RHEL 5.6 and later have an openldap24-libs-devel package that you can build against. This does not seam to be in the standard 5.6 repo. In which repo can I find that? Sorry, I was incorrect. It's in 5.7, not 5.6. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFUULsACgkQeiVVYja6o6NOCACeMVxKUmP3GFcRjE32W0l4kKVQ RM0An3/LiHMoat526fhNFNJ8nIDut6Lu =/OTu -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] sss_ssh_authorizedkeys returns Error looking up public keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/19/2013 02:27 PM, Mathieu Lemoine wrote: According to your configuration, SSSD is connecting anonymously to the LDAP server (you don't have a bind user or password configured). Can you install the openldap-clients package (or whatever its equivalent is for Ubuntu) and run the following command: ldapsearch -x -H ldap://ldap.office \ -b cn=users,dc=ldap,dc=office \ (uid=mlemoine) \ sshPublicKey My guess is that the sshPublicKey attribute will not be returned because the anonymous user is unlikely to have access to it. The solution to this would be to set the bind user for LDAP to an account that does have this privilege (or change the ACLs on the server so that the anonymous user can read that attribute. If it *is* returned, then there's a different problem. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFItpAACgkQeiVVYja6o6O4egCgkgxSUXEx43kzELR/Le90leZK 4awAoJ4fHOOOgR4qsNw/XLkmz1g+RNe7 =IGMr -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Problem limiting access to Users in Certain AD groups.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon 14 Jan 2013 04:28:57 PM EST, Jakub Hrozek wrote: On Mon, Jan 14, 2013 at 08:37:56PM +, Daniel Laird wrote: I am stuck with Ubuntu 10.04 (no chance of upgrading our servers). This means I am currently running SSSD 1.0.5. This is a very, very old version of SSSD. It hasn't been supported in ages. I want to limit which users can login. In later versions I believe I would use 'ldap_access_filter' Does that version have the simple access provider (man sssd-simple). If so, you could use that one. This would allow only users in the specified groups to login. Given my limitation on the version of SSSD can anyone help me achieve the same or is it not possible? I am a bit scared of rebuilding newer versions of SSSD. I would really urge you to upgrade. I'm CC-ing Timo Aaltonen, the Ubuntu SSSD maintainer. Timo, do you have maybe any PPA for 10.04 with more recent SSSD versions? SSSD was approved for a standing Micro Release Exception on January 8th[1], meaning that it's now on the list of packages that Ubuntu can opt to upgrade within a stable release. My understanding is that there are plans to backport SSSD 1.8 at least to the currently-supported Ubuntu releases, though Timo will have to confirm that for me (I'm only going from hearsay). [1] https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlD0e5YACgkQeiVVYja6o6PDIACdHE5sWzH+4BYOzsrP2tTkHKjD NJwAn0Trn7q/2diErOOCiswoK3wxTrSq =oqQU -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Password expiration with public-key authentication
On Tue 27 Nov 2012 03:51:55 PM EST, Iain Morgan wrote: Hello, I recently began experimenting with sssd (1.8.0) and have run into an issue with its support for password expiration. Specifically, the case where sssd is configured to use LDAP and the user authenticates via SSH public-key. If a user connects via ssh to a host which is using sssd and authenticates via a public-key, the only way to enforce password expiration appears to be to set ldap_pwd_policy=shadow. However, sssd will not attempt to change the password when the policy is thus set. I know that there are those who would argue that password expiration should not be enforced when public-key authentication is used, but that is an organizational policy decision. The expectation for the environment which I deal with is that password expiration should be enforced, and work, regardless of the method used for authentication. Is there some trick that I have overlooked or is this simply a design limitation? If the shadow map were exposed, pam_unix.so could be used to detect password expiration and pam_sss.so (with ldap_pwd_policy=none) could be used to change the password, but that is not currently the case. Try setting: access_provider = ldap ldap_access_order = expire ldap_account_expire_policy = shadow That should do what you're looking for. It tells the SSSD to honor shadow expiration/locking policy during the PAM_ACCT_MGMT phase. This phase will occur regardless of what authentication mechanism you use. ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] sssd equivilent of nss_ldap nss_getgrent_skipmembers?
On 10/25/2012 06:59 PM, Dmitri Pal wrote: On 10/25/2012 06:38 PM, Paul B. Henson wrote: On 10/25/2012 9:41 AM, Dmitri Pal wrote: BTW SSSD connects in an authenticated way. I assume you mean it supports connecting with authentication; considering I have provided it no credentials I would be surprised and disconcerted if it was doing anything other than an anonymous bind in my current deployment :). This is strange. By default SSSD prefers strong authentication methods like GSSAPI and you really need to twist its arms to go with anonymous bind. It might not be the default for the LDAP provider (provider is SSSD component that actually talks to DS) though... only for the advanced providers like IPA and AD. I just wanted to clarify this, because I think Dmitri is confused about the situation. There is NO requirement for authentication or encryption to perform LDAP id_provider lookups. By default we will use an unencrypted simple bind, because that will work in most cases. We support using an authenticated connection (and indeed this is the default in the AD and IPA providers), but it is not required unless the LDAP server to which you are connecting has disabled or limited anonymous access. In this situation, you can use simple bind authentication to a known bind DN with a password or you can use a GSSAPI SASL bind to connect to the LDAP server. This is in contrast to when the SSSD is using LDAP as an *authentication* provider. In this situation, we mandate that the LDAP connection be protected by encryption (one of LDAPS, LDAP+TLS or LDAP+GSSAPI) before we will allow it to perform a simple-bind auth for a user. This is done because the LDAP protocol will transport the simple-bind password in plaintext over the network, thereby making it very easy to snoop passwords. pam_ldap allowed this behavior but SSSD has forbidden it and will simply refuse to even attempt the authentication if the communication channel is not encrypted. Obviously, if you are using Kerberos or another auth provider, the above is academic. ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] sssd and difrent repositories
On 10/16/2012 08:25 AM, Longina Przybyszewska wrote: HI, Thanks, but actually I asked if I can use _Linux NIS_ server for authorization. You say I have to move NIS maps into AD and use Windows NIS – that means “no” ?. . All users at my site have accounts in AD, and in addition, Linux users have Linux accounts in respective NIS domains. In AD there are 3 domains for users accounts, in Linux, several other. Can WINdows NIS manage multi domains? I am not able to perform migration, as we have the Windows team dealing with MSWins and have to wait until they WILL do that. I have admin credentials but am not authorized to more than create user and computer account. Saying so – is there anything I can do now with sssd, in the existing env ironment, to improve authentication on Linux (using AD Kerberos for authentication and existing linux NIS server for the rest) ??? I think you misunderstood what Jakub was suggesting. If you use SSSD 1.9.2 and the AD provider, you can connect your Linux machines to AD without the need for NIS at all. UIDs/GIDs can be automatically generated from the objectSID value in Active Directory (see sssd-ad(5) for details). As Jakub mentioned, if you use the 'realmd' project, you can use its interfaces to easily configure SSSD to get identity and authentication data from Active Directory. ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
