[SSSD-users] Re: ldap_access_filter ignored for some users

[Jakub Hrozek]

On Mon, May 18, 2020 at 03:53:15PM +, Sajesh Singh wrote:
> If there were no PAM requests then what could be triggering SSSD to do the 
> lookup that I see in the logs?
> 
> -Sajesh-

Oh, sorry, you're right, there is pam_print_data also in the second
snippet. What log level was this gathered with? The pam responder logs
would be useful either way.
___
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: ldap_access_filter ignored for some users

[Jakub Hrozek]

On Mon, May 18, 2020 at 01:29:49PM +, Sajesh Singh wrote:
> Jakub,
>Both of the logins were via a web application that uses the underlying PAM 
> subsystem on the server.

Then you should look into the pam responder logs, too, because the back
end logs show no PAM request.
___
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: ldap_access_filter ignored for some users

[Jakub Hrozek]

On Fri, May 15, 2020 at 05:07:30PM +, Sajesh Singh wrote:
> CentOS 7.8
> SSSD 1.16.4
> 
> Having a strange issue where the ldap_access_filter seems to be applied to 
> some users and not others when they are both logging into the same 
> application that is using the underlying OS PAM configuration. Below are the 
> excerpts from the logs:
> 
> USERA log entires:
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [sdap_get_primary_name] 
> (0x0400): Processing object USERA
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [sdap_save_user] (0x0400): 
> Processing user USERA@default
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [sdap_save_user] (0x0400): 
> Original memberOf is not available for [USERA@default].
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [sdap_save_user] (0x0400): 
> User principal is not available for [USERA@default].
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [sdap_save_user] (0x0400): 
> Storing info for user USERA@default
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [sysdb_set_entry_attr] 
> (0x0200): Entry [name=USERA@default,cn=users,cn=default,cn=sysdb] has set 
> [ts_cache] attrs.
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [sdap_get_generic_ext_step] 
> (0x0400): calling ldap_search_ext with 
> [(&(memberuid=USERA)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0][dc=DOMAIN,dc=SUFFIX].
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [sysdb_set_entry_attr] 
> (0x0200): Entry [name=USERA@default,cn=users,cn=default,cn=sysdb] has set 
> [ts_cache] attrs.
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [dp_table_value_destructor] 
> (0x0400): Removing [0:1:0x0001:3::default:name=USERA@default] from reply table
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [pam_print_data] (0x0100): 
> user: USERA@default
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [sdap_access_send] (0x0400): 
> Performing access check for user [USERA@default]
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [sdap_access_filter_send] 
> (0x0400): Performing access filter check for user [USERA@default]
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [sdap_get_generic_ext_step] 
> (0x0400): calling ldap_search_ext with 
> [(&(uid=USERA)(objectclass=posixAccount)(objectClass=posixAccount)(accountActive=TRUE)(|(allowedService=unixAdmin)(allowedService=USERA)(allowedService=USERAAdmin)))][uid=USERA,ou=posixAccounts,ou=Apps,dc=DOMAIN,dc=SUFFIX].
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [sysdb_set_entry_attr] 
> (0x0200): Entry [name=USERA@default,cn=users,cn=default,cn=sysdb] has set 
> [ts_cache] attrs.
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [pam_print_data] (0x0100): 
> user: USERA@default
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [dp_get_account_info_handler] 
> (0x0200): Got request for [0x2][BE_REQ_GROUP][name=USERAadmin@default]
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [sdap_get_generic_ext_step] 
> (0x0400): calling ldap_search_ext with 
> [(&(cn=USERAadmin)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0][dc=DOMAIN,dc=SUFFIX].
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [sdap_get_primary_name] 
> (0x0400): Processing object USERAadmin
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [sdap_save_group] (0x0400): 
> Processing group USERAadmin@default
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [sdap_save_group] (0x0400): 
> Storing info for group USERAadmin@default
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [dp_table_value_destructor] 
> (0x0400): Removing [0:1:0x0001:2::default:name=USERAadmin@default] from reply 
> table
> (Fri May 15 12:35:01 2020) [sssd[be[default]]] [pam_print_data] (0x0100): 
> user: USERA@default
> (Fri May 15 12:40:01 2020) [sssd[be[default]]] [dp_get_account_info_handler] 
> (0x0200): Got request for [0x3][BE_REQ_INITGROUPS][name=USERA@default]
> (Fri May 15 12:40:01 2020) [sssd[be[default]]] [sdap_get_generic_ext_step] 
> (0x0400): calling ldap_search_ext with 
> [(&(uid=USERA)(objectclass=posixAccount)(&(uidNumber=*)(!(uidNumber=0][dc=DOMAIN,dc=SUFFIX].
> (Fri May 15 12:40:01 2020) [sssd[be[default]]] [sdap_get_primary_name] 
> (0x0400): Processing object USERA
> (Fri May 15 12:40:01 2020) [sssd[be[default]]] [sdap_save_user] (0x0400): 
> Processing user USERA@default
> (Fri May 15 12:40:01 2020) [sssd[be[default]]] [sdap_save_user] (0x0400): 
> Original memberOf is not available for [USERA@default].
> (Fri May 15 12:40:01 2020) [sssd[be[default]]] [sdap_save_user] (0x0400): 
> User principal is not available for [USERA@default].
> (Fri May 15 12:40:01 2020) [sssd[be[default]]] [sdap_save_user] (0x0400): 
> Storing info for user USERA@default
> (Fri May 15 12:40:01 2020) [sssd[be[default]]] [sysdb_set_entry_attr] 
> (0x0200): Entry [name=USERA@default,cn=users,cn=default,cn=sysdb] has set 
> [ts_cache] attrs.
> (Fri May 15 12:40:01 2020) [sssd[be[default]]] [sdap_get_generic_ext_step] 
> (0x0400): calling ldap_search_ext with 
> 

[SSSD-users] Re: restrict sudo su -

[Jakub Hrozek]

On Fri, Jan 17, 2020 at 11:23:25AM +0100, Pavel Březina wrote:
> On 1/17/20 8:40 AM, Jannis Mann wrote:
> > Hi,
> > I've implemented sssd with id, auth and access provider as ldap. So I am
> > using a binding account and didn't joined the domain with the server.
> > 
> > In general everything works. Only members of mentioned SG within the
> > sssd.conf can login to the server, just as I wish to.
> > 
> > However, as sudo user I can run something as following
> > 
> > sudo su - UserThatIsNotAllowed
> > 
> > So I (a sudo user) can switch to any user that is within the search base
> > I've specified in the sssd.conf
> > But these users are not allowed to use the server.
> > 
> > I understand that not the user himself is logging in but I actually
> > don't want sudo users to be able to switch to users that aren't allowed
> > on the server.
> > 
> > I'd like that it is only allowed to switch to users that are allowed on
> > the server on local accounts of course.
> > 
> > 
> > Is this a normal behaviour? Can it be changed?
> > 
> > Thank you!
> > Jannis
> 
> So you want to be able to run 'sudo su - AllowedUser' but not all users are
> allowed, right?
> 
> Sudo rules can match also command parameters so in theory you could create
> rule to allow commands "/bin/su - User1", "/bin/su - User2" ... but if you
> have many users, it would be tedious.
> 
> If the purpose is to allow specific users to be able to call all commands as
> allowed user, it would be better to use runAsUser ability of sudo (to run
> command as specific user instead of root) and just setup a rule like:
> 
> sudoUser: my-user
> sudoHost: ALL
> sudoCommand: ALL
> sudoRunAsUser: allowed-user

Couldn't you also put sudo into the acct pam substack? IIRC RHEL started
doing that some time ago..
___
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: Pros/cons of access_provider=ad + access.conf file vs access_provider=simple?

[Jakub Hrozek]

On Wed, Dec 04, 2019 at 09:58:00AM -0600, Spike White wrote:
> Sssd experts,
> 
> We have an AD-based sssd configuration that is working.  For RHEL6, 7 and 8.
> 
> We've done thorough lab testing + pilot projects.  All good (with certain
> RHEL6 restrictions).
> 
> Currently, we're using access_provider = simple, with the appropriate
> simple_allow_groups and simple_allow_users lines in /etc/sssd/sssd.conf.
> Works fine.
> 
> A reviewer mentioned we should be using access_provider = ad +
> /etc/security/access.conf file to restrict access.  (We have pam_access.so
> in our pam stack already, to disallow direct root login and other limited
> uses.)
> 
> Obviously that second approach would work too.
> 
> The claim is the first approach would allow in AD accounts with expired
> passwords and locked accounts.  Whereas the second approach would not.

This is correct. If would be an issue if you had used a different auth
method than passwords, like ssh keys, then locked accounts could log in.

The best way would be if sssd implemented account provider stacking so
that you could say:
access_provider=ad,simple
or such.

btw since you are already using AD, wouldn't it be best to implement
GPOs and use GPOs for access control, at least on RHEL-7 and 8? 

> 
> I'm attempting to test this claim -- I have an account I can lock easily.
> But does anyone have any best practices for access_provider?
> 
> The advantage of this first approach is that it's already coded and
> thoroughly tested.  The pilot projects use this.
> 
> The one advantage of the second approach that I'm certain of is that RHEL6
> does not have a realm permit command.  So to permit a user or group in
> RHEL6 using the first approach is different between RHEL6 and 7/8.  (To me,
> that's not huge.)
> 
> Spike

> ___
> 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 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: Enumerate users from external group from AD trust

[Jakub Hrozek]

On Tue, Nov 26, 2019 at 01:03:39PM -0500, John Desantis wrote:
> Jakub,
> 
> > > Is the functionality in question only available for IPA masters?
> >
> > It shouldn't be and I'm seeing the users also on a client. I don't
> > remember if there was ever a bug in the client portion, I guess
> > lookingat the logs would be the next step.
> 
> Alright, before I gather the logs do the IPA masters need to have
> "ignore_group_members" set to FALSE?

Yes, otherwise all groups appear empty.

> 
> Do you only need client logs with debug_level set to 10, or do you
> need server logs too?

I guess let's start with the client.
___
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: Debian10 and self-signed cert

[Jakub Hrozek]

On Tue, Nov 19, 2019 at 09:38:55AM +0200, Todor Petkov wrote:
> Hello,
> 
> I am trying to configure sssd authentication on Debian 10.2, sssd
> 1.16.3, against 389-ds with self-signed certificate.
> 
> In /etc/sssd/sssd.conf I have the line "ldap_tls_reqcert = never"
> line, but when I start sssd manually on the command line, it says "
> [sss_ldap_init_sys_connect_done] (0x0020): ldap_install_tls failed:
> [Connect error] [Key usage violation in certificate has been
> detected.]"
> 
> Can someone give me a hint how to teach sssd to ignore the certificate?

IIRC the reqcert option only allows you to suppress the CA chain
verification, so the cert doesn't then have to be signed by a trusted
CA. But it still has to have the key usage bits set to allow for TLS
server usage.
___
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: Enumerate users from external group from AD trust

[Jakub Hrozek]

On Thu, Nov 14, 2019 at 10:10:20AM -0500, John Desantis wrote:
> Jakub,
> 
> > This is confusing because the enumerate word is overloaded :-)
> 
> Ha!  Agreed.
> 
> > What is not supported and I guess won't be is "getent passwd" or "getent
> > group" to get all objects from AD.
> 
> I definitely agree with not being able to get all objects from AD via
> `getent passwd` or `getent group`.
> 
> > get AD members of an IPA group added through an external group, e.g.
> > "getent group ipagroup" should show both its IPA and AD group members.
> 
> This is exactly what I'm referring to.  On the IPA masters (which have
> their AD Trusts established), I can query an IPA group which has IPA
> and external members via `getent group blah` and see both IPA and AD
> users, as long as the following option is set within sssd.conf:
> 
> ignore_group_members = FALSE
> 
> But, on the IPA client nodes the only time that all group members will
> be shown is if:
> 
> 1.)  The users have previously logged into the node in question;
> 2.)  The users have been queried via `id user` or `getent passwd user`
> 
> Is the functionality in question only available for IPA masters?

It shouldn't be and I'm seeing the users also on a client. I don't
remember if there was ever a bug in the client portion, I guess
lookingat the logs would be the next step.
___
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: Enumerate users from external group from AD trust

[Jakub Hrozek]

On Wed, Nov 13, 2019 at 10:35:46AM -0500, John Desantis wrote:
> Hello all,
> 
> Apologies for the necromancy here, but there seems to be conflicting
> information regarding group enumeration within an IPA AD Trust,
> specifically, these tidbits:
> 
> > > >>> ad_users is an IPA group that contains an IPA external group that
> > > >>> contains the users, right?
> > > >>
> > > >> Correct.
> 
> > >  To confirm: Is the idea behind your patches that it will enumerate 
> > >  users in groups that have not logged before? Ie. I have no means to 
> > >  determine which users are in a group on the sssd/ipa side.
> 
> According to this thread and its linked bug reports, this was
> addressed in SSSD versions >= 1.14.0-43.  But, per the URL
> https://access.redhat.com/solutions/3597701 the following is stated:
> 
> "Enumeration is not supported in IPA-AD trust environments."
> "This is an expected behaviour if SSSD is not enumerating all AD
> users/groups on IPA server or client after setting enumerate = True
> and subdomain_enumerate = True in sssd.conf."
> 
> &
> 
> "Enumeration' is not supported in IPA-AD trust environments. As per
> confirmation from IPA/SSSD engineering team, there is no plan on
> supporting enumeration with IPA-AD trusts as it just wouldn't scale
> with large AD domains."
> 
> Our AD domain does permit enumeration as the sssd_nss.log on the IPA
> master didn't manifest a message stating that the domain does not
> support enumeration.
> 
> Given the aforementioned information, is it correct to assume that
> current versions of SSSD and IPA do not support enumerating a group
> which contains trusted AD users who haven't logged in before/been
> queried via `groups`, `id`, or `getent passwd`?

This is confusing because the enumerate word is overloaded :-)

What is not supported and I guess won't be is "getent passwd" or "getent
group" to get all objects from AD. What is supported since 1.14 was to
get AD members of an IPA group added through an external group, e.g.
"getent group ipagroup" should show both its IPA and AD group members.
___
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: Any way to get sssd to ignore gidNumber (Posix attribute) when auto_private_group set to true?

[Jakub Hrozek]

On Tue, Nov 05, 2019 at 09:00:44PM -0600, Spike White wrote:
> All,
> 
> We're replacing a commercial product that ignores whatever GID is used in
> gidNumber posix attribute, when auto_private_groups is set to true.
> 
> However, we find in sssd that even when we set auto_private_groups = True,
> that in additional to all the supplemental groups defined by memberOf, it
> also appends as the supplemental group the group whose GID is in gidNumber.
> 
> Is that any way to disable this?  To have sssd list only "memberOf" groups
> as supplemental groups when auto_private_groups == True?

Currently I can't think of anything systematic short of pointing gidNumber
to uidNumber.  (I have not tested this).

What's the rationale behind this? What problems does the additional
group pose?
___
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: sssd-session-recording

[Jakub Hrozek]

On Tue, Oct 22, 2019 at 12:51:27PM +, MAUPERTUIS, PHILIPPE wrote:
> Hi list,
> With Redhat 8 come tlogs for session recording.
> It seems a promising tool to comply with PCI DSS requirement 10.2 which 
> requires Monitoring of all actions taken by any individual with root or 
> administrative privileges.
> Redhat preferred way to configure tlog-rec-session is through sssd.
> I have doubt about the interaction between the nss  and the session-recording 
> sections.
> The man states :
>users (string)
>A comma-separated list of users which should have session 
> recording enabled.
>Matches user names as returned by NSS. I.e. after the possible 
> space
>replacement, case changes, etc.
> 
> Am I right to understand that if the nss filters some users (root for 
> example) with the filter_users directive, their sessions won't be recorded 
> even if defined in the session-recording session ?

Yes, that's my understanding, too.

> If yes is there a way to find the discrepancies between the two sections?

getent passwd -s sss $username, check if their shell is tlog-rec?

btw I guess you could just use chsh to change the user's shell to
tlog-rec..
___
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: autofs with samba AD

[Jakub Hrozek]

On Fri, Sep 27, 2019 at 01:05:17PM +0200, w...@mailbox.org wrote:
> 
> > Jakub Hrozek  hat am 27. September 2019 um 09:55 
> > geschrieben:
> > 
> > 
> > On Fri, Sep 27, 2019 at 09:34:42AM +0200, w...@mailbox.org wrote:
> > > 
> > > > Jakub Hrozek  hat am 26. September 2019 um 14:52 
> > > > geschrieben:
> > > > 
> > > > 
> > > > On Tue, Sep 24, 2019 at 01:21:45PM +0200, w...@mailbox.org wrote:
> > > > > Hello list, 
> > > > > I'm trying to setup sssd to access automounter rules stored on an AD 
> > > > > (samba 4.7.6).
> > > > > I followed the instructions on this site, however it doesn't work for 
> > > > > me.
> > > > > https://ovalousek.wordpress.com/2015/08/03/autofs/
> > > > > In the sssd_logfile I see, that the "auto.master" map is found by 
> > > > > sssd  within the ldap search path. 
> > > > > However, the reference to the auto.home and the corresponding user 
> > > > > mounts does not seem to be found. 
> > > > > 
> > > > > Using sssd to authenticate against Active Directory works well.
> > > > > 
> > > > > Any ideas what's going wrong here? Thanks for looking in this issue!
> > > > 
> > > > Normally when I debug automounter issues, I used to run automount -m on
> > > > the foreground in one terminal and try to correlate those with the sssd
> > > > logs tailing in another terminal.
> > > > 
> > > > Can you paste those?
> > > 
> > > Thanks, for your advice!
> > > I stopped the automounter daemon and run the automounter in the 
> > > foreground: 
> > > 
> > > root@fs1:~# automount -f -v
> > > Starting automounter version 5.1.2, master map /etc/auto.master
> > > using kernel protocol version 5.02
> > > no mounts in table
> > > 
> > > After that, I restart the sssd daemon and dump the automounter maps in 
> > > another terminal:
> > >   
> > > root@fs1:~# automount -m
> > > 
> > > autofs dump map information
> > > ===
> > > 
> > > global options: none configured
> > > no master map entries found
> > > 
> > > 
> > > However the automounter still gives no further output. 
> > > After that, I moved the empty /etc/auto.master away and restart the 
> > > automounter in the foreground: 
> > >   
> > > root@fs1:~# automount -f -v
> > > Starting automounter version 5.1.2, master map /etc/auto.master
> > > using kernel protocol version 5.02
> > > lookup(file): file map /etc/auto.master missing or not readable no mounts 
> > > in table
> > > 
> > > No additional output from the automounter after restarting sssd.
> > > In the logs of the sssd at startup I found the following:
> > >   
> > > ...
> > > (Fri Sep 27 08:13:46 2019) [sssd[be[info.privat]]] [dp_get_options] 
> > > (0x0400): Option ldap_autofs_search_base has value 
> > > ou=automount,dc=informatik,dc=privat
> > > ...
> > > (Fri Sep 27 08:13:46 2019) [sssd[be[info.privat]]] [dp_get_options] 
> > > (0x0400): Option ldap_autofs_map_master_name has value auto.master
> > > ...
> > > 
> > > Why is the automounter not looking for the maps from the sssd daemon? I 
> > > think, that the automounter doesn't communicate with the sssd daemon for 
> > > automounter maps, although the nsswitch.conf looks like this:
> > > 
> > > ...
> > > automount: files sss
> > > ...
> > > 
> > > 
> > > Do I miss something or how can I narrow down the problem?
> > 
> > Is the autofs responder of sssd running?
> 
> These processes are running concerning ssd: 
> /usr/sbin/sssd -i --logger=files
> /usr/lib/x86_64-linux-gnu/sssd/sssd_be --domain informatik.privat --uid 0 
> --gid 0 --logger=files
> /usr/lib/x86_64-linux-gnu/sssd/sssd_nss --uid 0 --gid 0 --logger=files
> /usr/lib/x86_64-linux-gnu/sssd/sssd_pam --uid 0 --gid 0 --logger=files
> /usr/lib/x86_64-linux-gnu/sssd/sssd_autofs --uid 0 --gid 0 --logger=files
> 
> 
> > Is libsss_autofs installed?
> 
> Seems to be installed:
> ./usr/lib/x86_64-linux-gnu/sssd/modules/libsss_autofs.so
> 
> 
> > 
> > If you strace automount, can you see it contacting the sssd socket?
> 
> Also the socket seems to be created:
> ls -l /var/lib/sss/pipes/
> total 4
>

[SSSD-users] Re: autofs with samba AD

[Jakub Hrozek]

On Fri, Sep 27, 2019 at 09:34:42AM +0200, w...@mailbox.org wrote:
> 
> > Jakub Hrozek  hat am 26. September 2019 um 14:52 
> > geschrieben:
> > 
> > 
> > On Tue, Sep 24, 2019 at 01:21:45PM +0200, w...@mailbox.org wrote:
> > > Hello list, 
> > > I'm trying to setup sssd to access automounter rules stored on an AD 
> > > (samba 4.7.6).
> > > I followed the instructions on this site, however it doesn't work for me.
> > > https://ovalousek.wordpress.com/2015/08/03/autofs/
> > > In the sssd_logfile I see, that the "auto.master" map is found by sssd  
> > > within the ldap search path. 
> > > However, the reference to the auto.home and the corresponding user mounts 
> > > does not seem to be found. 
> > > 
> > > Using sssd to authenticate against Active Directory works well.
> > > 
> > > Any ideas what's going wrong here? Thanks for looking in this issue!
> > 
> > Normally when I debug automounter issues, I used to run automount -m on
> > the foreground in one terminal and try to correlate those with the sssd
> > logs tailing in another terminal.
> > 
> > Can you paste those?
> 
> Thanks, for your advice!
> I stopped the automounter daemon and run the automounter in the foreground: 
> 
> root@fs1:~# automount -f -v
> Starting automounter version 5.1.2, master map /etc/auto.master
> using kernel protocol version 5.02
> no mounts in table
> 
> After that, I restart the sssd daemon and dump the automounter maps in 
> another terminal:
>   
> root@fs1:~# automount -m
> 
> autofs dump map information
> ===
> 
> global options: none configured
> no master map entries found
> 
> 
> However the automounter still gives no further output. 
> After that, I moved the empty /etc/auto.master away and restart the 
> automounter in the foreground: 
>   
> root@fs1:~# automount -f -v
> Starting automounter version 5.1.2, master map /etc/auto.master
> using kernel protocol version 5.02
> lookup(file): file map /etc/auto.master missing or not readable no mounts in 
> table
> 
> No additional output from the automounter after restarting sssd.
> In the logs of the sssd at startup I found the following:
>   
> ...
> (Fri Sep 27 08:13:46 2019) [sssd[be[info.privat]]] [dp_get_options] (0x0400): 
> Option ldap_autofs_search_base has value ou=automount,dc=informatik,dc=privat
> ...
> (Fri Sep 27 08:13:46 2019) [sssd[be[info.privat]]] [dp_get_options] (0x0400): 
> Option ldap_autofs_map_master_name has value auto.master
> ...
> 
> Why is the automounter not looking for the maps from the sssd daemon? I 
> think, that the automounter doesn't communicate with the sssd daemon for 
> automounter maps, although the nsswitch.conf looks like this:
> 
> ...
> automount: files sss
> ...
> 
> 
> Do I miss something or how can I narrow down the problem?

Is the autofs responder of sssd running?

Is libsss_autofs installed?

If you strace automount, can you see it contacting the sssd socket?
___
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: autofs with samba AD

[Jakub Hrozek]

On Tue, Sep 24, 2019 at 01:21:45PM +0200, w...@mailbox.org wrote:
> Hello list, 
> I'm trying to setup sssd to access automounter rules stored on an AD (samba 
> 4.7.6).
> I followed the instructions on this site, however it doesn't work for me.
> https://ovalousek.wordpress.com/2015/08/03/autofs/
> In the sssd_logfile I see, that the "auto.master" map is found by sssd  
> within the ldap search path. 
> However, the reference to the auto.home and the corresponding user mounts 
> does not seem to be found. 
> 
> Using sssd to authenticate against Active Directory works well.
> 
> Any ideas what's going wrong here? Thanks for looking in this issue!

Normally when I debug automounter issues, I used to run automount -m on
the foreground in one terminal and try to correlate those with the sssd
logs tailing in another terminal.

Can you paste those?
> 
> OS: Ubuntu 18.04.3 LTS
> sssd 1.16.1-1ubuntu1.4 
> sssd-ad 1.16.1-1ubuntu1.4
> sssd-ad-common  1.16.1-1ubuntu1.4 
> sssd-common 1.16.1-1ubuntu1.4 
> sssd-dbus  1.16.1-1ubuntu1.4 
> sssd-ipa   1.16.1-1ubuntu1.4 
> sssd-krb5  1.16.1-1ubuntu1.4 
> sssd-krb5-common 1.16.1-1ubuntu1.4 
> sssd-ldap   1.16.1-1ubuntu1.4 
> sssd-proxy  1.16.1-1ubuntu1.4 
> sssd-tools 1.16.1-1ubuntu1.4 
> 
> 
> 
> Here is the configuration. Additionally, I attached logfiles with log_level 9 
> 
> 
>  
> sssd.conf
> 
> [sssd]
> domains = info.privat
> config_file_version = 2
> services = nss, pam, autofs
> 
> [pam]
> 
> [nss]
> 
> [autofs]
> 
> [domain/info.privat]
> debug_level = 5
> ad_server = tfaddc2.info.privat
> access_provider = ad
> auth_provider = ad
> krb5_realm = INFO.PRIVAT
> cache_credentials = True
> id_provider = ad
> 
> autofs_provider = ad
> ldap_autofs_entry_key = cn
> ldap_autofs_entry_object_class = nisObject
> ldap_autofs_entry_value = nisMapEntry
> ldap_autofs_map_name = nisMapName
> ldap_autofs_map_object_class = nisMap
> ldap_autofs_search_base = ou=automount,dc=info,dc=privat
> 
> 
> nsswitch.conf
> 
> automount:  files sss
> 
> 
> AD
> 
> dn: OU=automount,DC=info,DC=privat
> objectClass: top
> objectClass: organizationalUnit
> ou: automount
> name: automount
> 
> dn: CN=auto.master,OU=automount,DC=info,DC=privat
> objectClass: top
> objectClass: nisMap
> cn: auto.master
> name: auto.master
> objectCategory: CN=NisMap,CN=Schema,CN=Configuration,DC=info,DC=privat
> nisMapName: auto.master
> 
> dn: CN=auto.home,OU=automount,DC=info,DC=privat
> objectClass: top
> objectClass: nisMap
> cn: auto.home
> name: auto.home
> objectCategory: CN=NisMap,CN=Schema,CN=Configuration,DC=info,DC=privat
> nisMapName: auto.home
> 
> dn: CN=/home/,CN=auto.master,OU=automount,DC=info,DC=privat
> objectClass: top
> objectClass: nisObject
> objectCategory: CN=NisObject,CN=Schema,CN=Configuration,DC=info,DC=privat
> nisMapName: auto.master
> cn: /home/
> name: /home/
> nisMapEntry: auto.home
> 
> dn: CN=user1,CN=auto.home,OU=automount,DC=info,DC=privat
> objectClass: top
> objectClass: nisObject
> objectCategory: CN=NisObject,CN=Schema,CN=Configuration,DC=info,DC=privat
> nisMapName: auto.home
> nisMapEntry: -fstype=nfsv4,nosuid,rw,dir_index,user_xattr,proto=tcp,port=2049 
> server:/export/lra/user/user1
> cn: user1
> name: user1


> ___
> 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 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: Offline caching of group names and memberships?

[Jakub Hrozek]

On Wed, Sep 25, 2019 at 06:25:06PM -0500, Spike White wrote:
> Yes, true statement.
> 
> We also do not own AD -- only the Linux builds.  The AD admins insist on
> camel-case for group names and user names.
> 
> Yes,  AD and Windows are case-insensitive. But Linux and Kerberos are not.
> 
> I know these logins by default are translated into lower-case names (which
> is what we desire anyway).  I forget which sssd setting does this
> auto-lower-casing.

case_sensitive = true|false|preserving

false is the default for AD in the sense that everything is lowercased
and names match in case-insensitive manner.

true is the default for generic LDAP, names are returned in the original
case and must be matched in the original case

preserving is a little in between in the sense that the original case is
returned but you can match on any case.

> 
> BTW, that would be a cool RFE for pam_sss.so to return cache entries if
> sssd service down or wedged.  I imagine it'd be a flag on the auth
> pam_sss.so line that you're add to enable this.

Do you think it is needed over the case_sensitive option?
___
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: sssd-krb5, krb5_ccachedir, DIR-cache-store...

[Jakub Hrozek]

On Sun, Sep 22, 2019 at 04:16:58PM -, Jostein Fossheim wrote:
> We are working with several kerberos-REALMS and are trying to get our clients 
> to store their kerberos tickets in a DIRECTORY. This seems to work nicely for 
> clients not authenticating at login, with the following configuration set in 
> /etc/krb5.conf. 
> ...
> [libdefaults]
> ...
> 
> default_ccache_name = DIR:/tmp/krb5cc_%{uid}
> ...
> 
> user@server:~$ klist
> Ticket cache: DIR::/tmp/krb5cc_888/tkt
> Default principal: user@REALM
> 
> Valid starting ExpiresService principal
> 09/22/19 17:35:50  09/23/19 17:35:48  krbtgt/user@REALM
> 
> Each ticket is stored in a separate file.  
> 
> For clients using sssd for login, I want to set up the same behavior. But 
> when I attempt to login the system creates an "/tmp/krb5cc_${UiD}" - but here 
> the directory don't get the excutable bit set (that is the directory get 
> 0600-permission), and the login fails.  
> 
> In the man-page from Debian-buster (sssd-version: 1.16.3), there are to 
> settings that seems to regulate this behaviour : 
> 
> krb5_ccachedir (string)
> Directory to store credential caches. All the substitution sequences of 
> krb5_ccname_template can be used here, too, except %d and %P. The directory 
> is created as private and owned by the user, with permissions set to 0700.
> 
> Default: /tmp
> 
> krb5_ccname_template (string)
> Location of the user's credential cache. Three credential cache types are 
> currently supported: "FILE", "DIR" and "KEYRING:persistent". The cache can be 
> specified either as TYPE:RESIDUAL, or as an absolute path, which implies the 
> "FILE" type. In the template, the following sequences are substituted:
> 
> [...]
> 
> If the template ends with 'XX' mkstemp(3) is used to create a unique 
> filename in a safe way.
> 
> When using KEYRING types, the only supported mechanism is 
> "KEYRING:persistent:%U", which uses the Linux kernel keyring to store 
> credentials on a per-UID basis. This is also the recommended choice, as it is 
> the most secure and predictable method.
> 
> The default value for the credential cache name is sourced from the profile 
> stored in the system wide krb5.conf configuration file in the [libdefaults] 
> section. The option name is default_ccache_name. See krb5.conf(5)'s PARAMETER 
> EXPANSION paragraph for additional information on the expansion format 
> defined by krb5.conf.
> 
> NOTE: Please be aware that libkrb5 ccache expansion template from 
> krb5.conf(5) uses different expansion sequences than SSSD.
> 
> Default: (from libkrb5)
> 
> ...
> 
> I have tried to both set and unset, the two parameters in question like this: 
> 
> krb5_ccachedir = /tmp/krb5cc_%U
> 
> krb5_ccname_template = DIR: %d
> krb5_ccname_template = DIR:%d/krb5cc_%U_XX
> 
> But the configuration-options seems to be ignored, no matter what I do, and I 
> have the same behavior: A non-executable directory is created and the user is 
> unable to login. 
> 
> If I set the +x bit on the directory manually as the root-user, everything 
> works. 

First, the DIR cache is not the most tested, to the best of my knowledge
no distribution uses it as the default. RHEL-6 uses FILE, RHEL-7 KEYRING
and RHEL-8 KCM. Looking at the code, the directories should be created
with 0700. I wonder if the permissions are OK if you use
/run/user/%uid/ccache or something similar instead?

Is there a reason to not use KEYRING?
___
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: Questions about the PAC responder

[Jakub Hrozek]

On Wed, Sep 18, 2019 at 06:25:31PM -0700, Jim Burwell wrote:
> Hi,
> 
> I recently encountered issues where logins on Linux clients using SSSD
> and the AD provider, pointed directly to an AD server were randomly
> slow.  Randomly meaning, some clients experienced no slowness at all,
> other clients consistently had slow logins (30+ seconds sometimes), and
> yet other clients had random normal/fast logins, and frequent slow logins.
> 
> Through troubleshooting, log analysis and experimentation, it appears
> the fix for this issue is to turn off the PAC service.  Once "pac" was
> removed from the "services =" line in sssd.conf, the problem client
> boxes were suddenly consistently fast in terms of user logins.
> 
> This deployment has the clients talking directly to AD servers it looks
> up via the normal AD DNS entries, and uses Unix POSIX attributes in AD
> for uidnumber and gidnumber etc (e.g. it's not doing any SID -> unix ID
> translations, it's just pulling them directly from LDAP attributes).
> 
> I guess my questions are:
> 
>  1. What does PAC actually do?  I've read that it lists a users group as
> part of a KRB5 response, but also that it might be involved in
> cross-domain trusts.

There is a lot of information about PAC in the PFD linked here:

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/166d8064-c863-41e1-9c23-edaaa5f36962?redirectedfrom=MSDN
and a more readable version e.g. here:
https://www.freeipa.org/page/Howto/Inspecting_the_PAC

In general, Windows gives you the authoritative set of groups the user
is a member of only after login, so parsing the groups out of the PAC is
the most reliable way. And in older versions of SSSD, especially with
IPA-AD trusts, it was even the only way, IOW 'id' would only display
groups after you log in. Newer versions try to approximate the groups
with other means, mostly the tokenGroups attribute.

>  2. When is PAC needed.  Is it only needed for deployments using IPA?

It was strictly needed with some quite old IPA provider versions and
recommeded at some point for AD provider also, but in the meantime, we
improved the tokenGroups codepath,so the PAC provider is no longer used
for AD provider, at least by default.

>  3. Is there any impact in turning off PAC if the architecture doesn't
> involve IPA in the mix?

As said above, it is the most reliable way, but if sssd is giving you
the group membership you expect also w/o using the PAC, then feel free
to not use it.

>  4. Why would PAC slow down such a architecture seemingly randomly?

I guess you might be using an older version of SSSD? In the older
versions, the PAC was processed as part of the krb5_child process, so if
the PAC processing was taking too long, the krb5_child was timing out.
In newer versions, the PAC handling was reworked and is now evaluated
differently.

The PAC data is cached iirc, so when the slowdown occured, I guess it
was when the PAC data was out of date in the cache.

> 
> I've done a bit of searching and have only found sparse information on
> sssd_pac, some in Jakob's blog!  I'm trying to understand its role.
> 
> 
> Thanks,
> 
> - Jim
> 

> ___
> 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 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: [AD] Filter out disabled users

[Jakub Hrozek]

On Wed, Sep 11, 2019 at 09:04:40PM +0200, Hinrikus Wolf wrote:
> Hi,
> 
> that's actually what we tried:
> 
> 
> > [sssd]
> > domains = fsmpi.rwth-aachen.de
> > config_file_version = 2 
> > services = nss, pam 
> > 
> > [pam]
> > offline_credentials_expiration = 1 
> > offline_failed_login_attempts = 3 
> > offline_failed_login_delay = 0 
> > 
> > [domain/fsmpi.rwth-aachen.de]
> > ad_domain = fsmpi.rwth-aachen.de
> > krb5_realm = FSMPI.RWTH-AACHEN.DE
> > 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 = False
> > use_fully_qualified_names = False
> > fallback_homedir = /home/%u
> > access_provider = ad
> > enumerate = true
> > ldap_user_fullname = displayName
> > krb5_lifetime = 48h 
> > krb5_renewable_lifetime = 200h
> > krb5_renew_interval = 30m 
> > ad_gpo_access_control = disabled
> > ad_enable_gc = false
> > ldap_search_base = 
> > dc=fsmpi,dc=rwth-aachen,dc=de?subtree?(&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
> 
> Do you know what we did wrong?

Not really, did you try running ldapsearch using this filter?
___
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: another ubuntu 18 sssd issue: cron

[Jakub Hrozek]

btw I think it would be prudent for Ubuntu to include 'sss' by default
as well. There's very little downside to it even if sssd is not running
(if the answer is not found in nss_files or if all databases are to be
consulted, nss_sss tries to open a socket towards sssd, fails) and
RHEL has been doing that since RHEL-7 at least, IIRC even since some
later RHEL-6 releases.

btw here is a RHEL bug (open since 2004..) that asks for libc to implement
auto-reloading:
https://bugzilla.redhat.com/show_bug.cgi?id=132608
unfortunately it doesn't link to the glibc upstream bugzilla. But I
completely trust the glibc developers that this is non-trivial.

On Thu, Aug 29, 2019 at 01:43:07PM +, Charles Hedrick wrote:
> Cute. I wondered why the problem didn’t happen on Centos. That explains it, 
> but wasn’t at all the explanation I was expecting.
> 
> On Aug 26, 2019, at 9:41 AM, Jakub Hrozek 
> mailto:jhro...@redhat.com>> wrote:
> 
> Fedora/RHEL includes 'sss' in nsswitch.conf by default precisely for
> this reason.
> 

> ___
> 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 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: Group disappears from users / no group name gets resolved

[Jakub Hrozek]

On Mon, Aug 26, 2019 at 04:25:38PM -, Jamal Mahmoud wrote:
> Hi Jakub,
> 
> I've managed to catch the error again with my own machine so this time i've 
> had time to properly capture the issue. I've been looking into the logs and 
> what seems to be happening is that we have multiple AD Domains Active. I want 
> to know if this is heard of, our local AD domain and a trusted forest are 
> being used as Active domains in ldap searches. Our local AD responds to a be 
> request from sssd_be and fills the correct group into the nss cache, then it 
> gets a response from the trusted domain and the group doesn't exist so it 
> overwrites the cache with no such group. I think the intermittent issue 
> occurs because sometimes ldap will query the remote forest and other times 
> the local. Please advise on whether this is plausible or not. 

It would be nice to see some log snippet to see the behaviour exactly,
but in general, requests towards the trusted back ends should be
sequential. The only similar pattern might be where sssd first checks
with the help of the global catalog which domain the group resides at
and then queries that domain's LDAP port.
___
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: another ubuntu 18 sssd issue: cron

[Jakub Hrozek]

On Mon, Aug 26, 2019 at 01:37:43PM +, Charles Hedrick wrote:
> After converting a system to sssd with an IPA backend, we found that cron was 
> not recognizing our users. It appears (based on using lsof to see what .so 
> files are open) that cron is reading nsswitch.conf at startup, and doesn’t 
> notice the change when sssd setup adds sss to the user map in nsswitch.conf. 
> Restarting cron fixes it, but we’ve now got another Ubuntu-specific hack in 
> our Ansible setup script.

This is not specific to RHEL or Ubuntu, this is how libc behaves.

Fedora/RHEL includes 'sss' in nsswitch.conf by default precisely for
this reason.
___
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: Patch for sssd to fix recursion problems with Winbind (Samba Bug #13815)

[Jakub Hrozek]

On Fri, Aug 23, 2019 at 03:46:54PM +0200, Heiko Wundram wrote:
> Hello list,
> 
> for a deployment I'm administering, I'm using winbind and sssd in parallel,
> both for different authentication sources (so it's not about their
> interoperability, but rather about using them in parallel). It seems that
> sssd has/had a bug which meant that winbind 4.8+ and sssd, if used together
> as NSS sources, would, for unavailable accounts in both authentication
> sources, lead to a DoS against winbind due to recursive calls of the NSS
> infrastructure. I'm deploying winbind (for a Windows Domain) and sssd (for
> an LDAP authentication source with client certificate authentication) on
> Debian 10.
> 
> Samba tracked this as bug #13815
> (https://bugzilla.samba.org/show_bug.cgi?id=13815), which contains a link to
> a corresponding issue in the RedHat bugtracker
> (https://bugzilla.redhat.com/show_bug.cgi?id=1666819), which supposedly
> contains a patch for the behaviour; as the bug isn't open, I can neither see
> what the patch actually is, nor can I prepare the patch for the Debian
> packaging of sssd.
> 
> Can anybody shed some light on what the patch is (and/or link to the commit
> in Pagure), specifically also which published version the patch is contained
> in, so that I might either decide to deploy updated sssd packages for
> Debian, or even try to backport the patch to the Debian built-in version? I
> can't find a means to search commits in Pagure, that's why I'm asking here,
> but even just that would be helpful.
> 
> Thanks in advance!

the corresponding upstream tickets are:
https://pagure.io/SSSD/sssd/issue/3963
and:
https://pagure.io/SSSD/sssd/issue/3964

I /think/ it might be possible to work around the bug by setting:
local_negative_timeout = 0
in the [nss] section.
___
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: Group disappears from users / no group name gets resolved

[Jakub Hrozek]

On Thu, Aug 22, 2019 at 11:11:18AM -, Jamal Mahmoud wrote:
> We've been experiencing an intermittent issue relating to SSSD v1.15.2, we 
> are running CentOS7.4 on our workstations. We use SSSD to communicate with 
> our Active Directory to pull users for auth. The majority of users have a 
> certain group set as their primary group and some departments have it as an 
> additional group. Most of the time this group works fine on all workstations 
> but sometimes we will run into an issue where a user can no longer access the 
> privileges attained from the group. For users who have it set as primary, the 
> id command returns a gid without the name and for users who have it as an 
> additional group, it doesn't appear at all. I've managed to capture output 
> from sssd services and there are a few interesting lines that I thought I 
> should share with you as I don't understand what they mean. I should add that 
> when this error occurs, restarting the sssd.service usually works, if not, 
> sss_cache -E works, and if that doesn't work, removing the workstation from 
> the realm, de
>  leting the sssd db and rejoining seems to be the final trick that works. 

I'm not sure if this is a helpful response, but I would strongly
encourage to upgrade to 1.16.x. It is quite stable and 1.15.x is not
going to receive any fixes from either RH or upstream.

> 
> Regarding the logs, the symptoms I noted are below: 
> 1. getent group *mygroup* returns nothing
> 2. id user returns a gid without a resolved group name (if it is a primary 
> group)
> 3. I had to leave the realm, delete the db and rejoin to get sssd to work 
> properly again. 
> 
> in sssd_nss.log i found this entry: 
> (Wed Aug 21 16:22:45 2019) [sssd[nss]] [nss_get_grent] (0x0040): Incomplete 
> group object for gr...@domain.com[0]! Skipping

An 'incomplete' group in sssd-lingo is an optimization stub. In cases
where the flow doesn't need the full group to be resolved, it is not,
only an entry that is internally marked as incomplete is added to the
cache.

It would be more interesting to see sssd logs when you call "getent
group $gidnumber" for the group whose number does not resolve.

> 
> and in the sssd_domain.com.log:
> (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] 
> [sdap_nested_group_split_members] (0x4000): [CN=USER,OU=IT Privileged 
> accounts,DC=domain,DC=com] is unknown object
> (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] 
> [sdap_nested_group_process_send] (0x0400): More members were missing than the 
> deref threshold
> (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] 
> [sdap_nested_group_process_send] (0x2000): Looking up 11/224 members of group 
> [CN=GROUP,OU=Security,OU=Groups,OU=Place St,OU=Offices,DC=domain,DC=com]
> (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] 
> [sdap_nested_group_process_send] (0x2000): Dereferencing members of group 
> [CN=GROUP,OU=Security,OU=Groups,OU=Place St,OU=Offices,DC=domain,DC=com]
> (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_deref_search_send] 
> (0x2000): Server supports ASQ
> (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_asq_search_send] 
> (0x0400): Dereferencing entry [CN=GROUP,OU=Security,OU=Groups,OU=Place 
> St,OU=Offices,DC=domain,DC=com] using ASQ
> (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_print_server] 
> (0x2000): Searching XXX.XXX.XXX.XXX:389
> (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_get_generic_ext_send] 
> (0x0400): WARNING: Disabling paging because scope is set to base.
> (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_get_generic_ext_step] 
> (0x0400): calling ldap_search_ext with [no 
> filter][CN=GROUP,OU=Security,OU=Groups,OU=Place 
> St,OU=Offices,DC=domain,DC=com].

This looks fine, it's just sssd looking up all the members of the group.

> 
> I've redacted the entries but I'm sure you can get the jist of whats 
> happening here hopefully. If there is anything else you need, please do not 
> hesitate to ask! If these logs don't point to anything could you maybe 
> provide some advice on what to look for when parsing? 
> 
> Thanks,
> Jamal
___
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: Problem getting sssd to work with LDAP authentication

[Jakub Hrozek]

On Mon, Aug 12, 2019 at 07:21:15PM -, Jane Eason wrote:
> We do not have the uid number in LDAP. 
> 
> In our LDAP uid is the username, so LDAP has e.g. uid=bob. There is a local 
> Linux user named "bob" as well (we are not creating accounts on login). 
> 
> We thought we could get around having to have the uid number in LDAP, using 
> the following line in sssd.conf:
> 
>  ldap_user_uid_number = uid
>  
> so at least the ldap query would return something. 
> 
> When "bob" tries to login we do see bob's attributes returned from the sssd 
> ldap query, but it stops there without any attempt at an LDAP bind from bob.
> 
> Here is the result of an ldapsearch with objectclass=inetorgperson uid=\* 
> 
> dn: uid=bob,ou=people,ou=primary,ou=eid,dc=my,dc=edu
> mail: b...@my.edu
> uid: bob
> initials: B
> givenName: Bob
> sn: Barker
> objectClass: inetOrgPerson
> objectClass: myPerson
> objectClass: eduPerson
> objectClass: organizationalPerson
> objectClass: Person
> objectClass: ndsLoginProperties
> objectClass: Top

What is typically meant by UID in the sssd context is not the LDAP uid
attribute, but a numerical identifier (user-ID). It looks like your
entries in LDAP don't have them.

Typically what is done is that the entries also receive the posixAccount
objectclass and then you'd add a uidNumber and a gidNumber.

Without a UID number or a way to map the UID number with some other
means (right know that would be from a Windows SID), SSSD cannot resolve
those users.

(An exception is an application domain where you only use the LDAP users through
the D-Bus API by an app, but I'm guessing that's not what you are after)
___
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: Problem getting sssd to work with LDAP authentication

[Jakub Hrozek]

On Fri, Aug 09, 2019 at 08:33:43PM -, Jane Eason wrote:
> Our LDAP does not include the POSIX schema, so we made a couple of entries in 
> sssd.conf to attempt to work around that.
> 
> Here is our complete (slightly redacted) sssd.conf:
> 
> [domain/mydomain]
> id_provider = ldap
> auth_provider = ldap
> access_provider = ldap
> ldap_uri = ldaps://mydomain.my.edu
> ldap_search_base = ou=people,ou=primary,ou=eid,dc=my,dc=edu
> ldap_default_bind_dn = cn=my-proxy,ou=proxies,dc=my,dc=edu
> ldap_default_authtok = REDACTED
> ldap_access_filter = uid=*
> ldap_schema = rfc2307
> cache_credentials = false
> ldap_user_object_class = inetorgperson
> ldap_id_mapping = false
> ldap_user_uid_number = uid

Are you sure your user ID are stored in the uid attribute? Because in
the earlier log snippet, sdap_save_user was complaining about missing
UID:

(Thu Aug  8 16:45:53 2019) [sssd[be[mydomain]]] [sdap_save_user] (0x0020): 
Cannot retrieve UID for [myuser@mydomain] in domain [mydomain]
(Thu Aug  8 16:45:53 2019) [sssd[be[mydomain]]] [sdap_save_user] (0x0020): 
Failed to save user [myuser@mydomain]
___
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: [AD] Filter out disabled users

[Jakub Hrozek]

On Sun, Jul 21, 2019 at 06:08:18PM +0200, Hinrikus Wolf wrote:
> Hi,
> 
> we are currently running a Samba AD DC Server with sssd on clients. Now
> we want to run sssd also on our mail server with postfix + dovecot.
> Postfix and dovecot get their users from NSS i.e. from sssd.
> In our Domain there are several disabled users (via User Account Control
> Bit). Any of these users are listed in NSS.
> 
> Unfortunately, they can receive emails, because they are existing in the
> user database of NSS. But they cannot login to read mails or even answer.
> 
> We would like to filter out disables users from NSS s.t. postfix will
> not accept emails for disabled users.
> 
> We searched in man 5 sssd-ad but did not find a config option for this
> use case.
> 
> Do you have any idea what we could do to achieve the desired behaviour?

See man sssd-ldap, you can add any of the ldap_* options to
id_provider=ad as well, including the ldap_search_base which in turn can
include the UAC.

I don't have a ready example with the needed UAC value, though.
___
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: override_gid not applying to trusted/parent AD domains when joined via child

[Jakub Hrozek]

On Thu, Aug 08, 2019 at 02:31:32PM -0400, Josh Snyder wrote:
> On Thu, Aug 8, 2019 at 2:05 PM Sumit Bose  wrote:
> 
> > On Thu, Aug 08, 2019 at 01:25:08PM -0400, Josh Snyder wrote:
> > > Hi All,
> > >
> > > I'm working in a proof of concept for a customer where I've been asked to
> > > join the child domain of a Microsoft Active Directory domain,
> > > child.example.com.  Users will primarily exist in the parent,
> > example.com,
> > > but some users will also exist in the child.  The application requires
> > that
> > > all users have a specific primary GID, 1100, which is defined in
> > /etc/group
> > > and I'm attempting to apply via override_gid.
> > >
> > > User authentication via either the child or parent is successful,
> > however,
> > > the override_gid is only applied to users of the child, @
> > child.example.com
> > > and NOT for users of the parent, @example.com.
> > >
> > > I saw what looked to be a similar post to this list from Sep 2018.  It
> > was
> > > suggested this may be a bug.  I didn't see a follow-up/resolution to that
> > > thread.  Is this issue being tracked or has it been resolved?
> >
> > Hi,
> >
> > in contrast to other options the override_gid options is not
> > automatically inherited to sub-domains (from the SSSD point of view). I
> > think this is better than the other way round because the given GID
> > might make sense in one domain but not in the other.
> >
> > The version of SSSD you are using allows to set options for sub-domains
> > individually. Please try to add:
> >
> >
> > [domain/child.example.com/example.com]
> > override_gid = 1100
> >
> > to sssd.conf. This works for many options but I have not tested
> > override_gid yet. Sp please let me know if this works or not.
> >
> >
> Thanks for the suggestion, unfortunately, I have tried to define an
> override_gid that's in a specific domain declaration as your above example,
> but it does not appear to have an impact.
> 
> I tested scenarios where I had a host joined directly to the parent, but
> override_gid was not applied for the child.  Likewise, I tested a scenario
> where my host is joined directly to the child, but override_gid is not
> applied for the parent.
> 
> The override_gid seems to only be applied for users that are specifically
> authenticated against the directly joined domain and not applied for any
> trusted domains. And additional [domain] declarations containing
> override_gid do not appear to be applied.

Yes, unfortunately code-wise we have two way of reading configuration
option, one where the option is directly read from the domain's
configuration database for a domain and then another one mostly used
for provider-specific options (think ad_server, ldap_uri, ...). Only the
latter group of options is inherited unfortunately.
___
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: socket activated services and "implicit" sssd.conf?

[Jakub Hrozek]

On Thu, Aug 01, 2019 at 07:50:09PM +0300, Timo Aaltonen wrote:
> 
> Hi,
> 
> As discussed on irc, the fallback config enables 'services=nss', and
> check_socket_activated_responder() bails out if there's no conffile.
> 
> So both should be fixed to allow sssd to start without extra noise when
> socket activation is enabled and no conffile around (the default case
> when the package is installed).

Can you file tickets?
___
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: [AD] User discovery/enumeration issue due to domain settings

[Jakub Hrozek]

On Tue, Jul 30, 2019 at 06:42:06PM +0200, Christian Lamparter wrote:
> Hello again,
> 
> On Fri, 2019-07-26 at 14:08 +0200, Jakub Hrozek wrote:
> > On Fri, Jul 26, 2019 at 12:50:16PM +0200, Christian Lamparter wrote:
> > > I'm currently setting up sssd (Debian 1.16.3) on Debian Buster 10.0
> > > and I ran into a problem that I was able to trace down to the domain
> > > permission/security settings that placed the users into a special OU
> > > that machine accounts can't read.
> > > 
> > > First a bit of background:
> > > Currently, there's a way to use winbind + friends in order to join
> > > and auth users on the domain. But due to limitations (unreliable
> > > no home directories, gid/uid mapping issues, etc.), I want to give
> > > sssd a try and I tested this with both of the current Debian sssd
> > > version 1.16.3 and 2.2.0-4 (from unstable / sid / rolling release).
> > > 
> > > I successfully used the "realm" utility to discover and setup the
> > > sssd.conf
> > > ===
> > > # realm discover -v DOMAIN (named changed)
> > >  * Resolving: _ldap._tcp.domain
> > >  * Performing LDAP DSE lookup on: 1x.y.z.1
> > >  * Performing LDAP DSE lookup on: 1z.a.b.c
> > >  * Performing LDAP DSE lookup on: 1d.e.f.g
> > >  * Successfully discovered: domain
> > > domain
> > >   type: kerberos
> > >   realm-name: DOMAIN
> > >   domain-name: domain
> > >   configured: no
> > >   server-software: active-directory
> > >   client-software: sssd
> > >   required-package: sssd-tools
> > >   required-package: sssd
> > >   required-package: libnss-sss
> > >   required-package: libpam-sss
> > >   required-package: adcli
> > >   required-package: samba-common-bin
> > > 
> > > # realm join -v -U me@DOMAIN domain
> > >  * Resolving: _ldap._tcp.domain
> > >  * Performing LDAP DSE lookup on: 1x.y.z.1
> > >  * Performing LDAP DSE lookup on: 1z.a.b.c
> > >  * Performing LDAP DSE lookup on: 1d.e.f.g
> > >  * Successfully discovered: domain
> > > Password for me@DOMAIN: ***
> > > * Unconditionally checking packages
> > >  * Resolving required packages
> > >  [...]
> > >  * Generated 120 character computer password
> > >  * Using keytab: FILE:/etc/krb5.keytab
> > >  * Found computer account for COMPUTER
> > >  * Set computer password
> > >  * Retrieved kvno '14' for computer account in directory: ...
> > >   * Modifying computer account: userAccountControl
> > >  * Modifying computer account: operatingSystemVersion,
> > > operatingSystemServicePack
> > >  * Modifying computer account: userPrincipalName
> > >  * Cleared old entries from keytab: FILE:/etc/krb5.keytab
> > >  * Discovered which keytab salt to use
> > >  * Added the entries to the keytab: ...
> > >  * /usr/sbin/update-rc.d sssd enable
> > >  * /usr/sbin/service sssd restart
> > >  * Successfully enrolled machine in realm
> > > ===
> > > 
> > > /etc/sssd/sssd.conf
> > > 
> > > [sssd]
> > > domains = domain
> > > config_file_version = 2
> > > services = nss, pam, ifp # added ifp
> > > 
> > > [domain/domain]
> > > ad_domain = domain
> > > krb5_realm = DOMAIN
> > > 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 = True
> > > fallback_homedir = /home/%u@%d
> > > access_provider = ad
> > > ===
> > > 
> > > klist shows a valid ticket and everything seemed to be working.
> > > 
> > > 
> > > But when I was trying to login (yes, I made sure that my time is synced
> > > and I made sure /etc/nssswitch.conf was correct) with my "me@domain"
> > > login it never worked. I tried also id me@domain and sssctl (had to add
> > > ifp, seems like realm doesn't add) but it wasn't working for my login.
> > > 
> > > After trying a lot of different combinations with different id,
> > > auth_providers and ldap I discovered that the AD Server is setup
> > > in such a way (probably due to DSVGO) that the Domain-PC Accounts
> > > are not allowed to read from the OU where all the staff users are
> > > placed. And indeed, when I copied

[SSSD-users] Re: [AD] User discovery/enumeration issue due to domain settings

[Jakub Hrozek]

On Fri, Jul 26, 2019 at 12:50:16PM +0200, Christian Lamparter wrote:
> Hello Folks,
> 
> I'm currently setting up sssd (Debian 1.16.3) on Debian Buster 10.0
> and I ran into a problem that I was able to trace down to the domain
> permission/security settings that placed the users into a special OU
> that machine accounts can't read.
> 
> First a bit of background:
> Currently, there's a way to use winbind + friends in order to join
> and auth users on the domain. But due to limitations (unreliable
> no home directories, gid/uid mapping issues, etc.), I want to give
> sssd a try and I tested this with both of the current Debian sssd
> version 1.16.3 and 2.2.0-4 (from unstable / sid / rolling release).
> 
> I successfully used the "realm" utility to discover and setup the
> sssd.conf
> ===
> # realm discover -v DOMAIN (named changed)
>  * Resolving: _ldap._tcp.domain
>  * Performing LDAP DSE lookup on: 1x.y.z.1
>  * Performing LDAP DSE lookup on: 1z.a.b.c
>  * Performing LDAP DSE lookup on: 1d.e.f.g
>  * Successfully discovered: domain
> domain
>   type: kerberos
>   realm-name: DOMAIN
>   domain-name: domain
>   configured: no
>   server-software: active-directory
>   client-software: sssd
>   required-package: sssd-tools
>   required-package: sssd
>   required-package: libnss-sss
>   required-package: libpam-sss
>   required-package: adcli
>   required-package: samba-common-bin
> 
> # realm join -v -U me@DOMAIN domain
>  * Resolving: _ldap._tcp.domain
>  * Performing LDAP DSE lookup on: 1x.y.z.1
>  * Performing LDAP DSE lookup on: 1z.a.b.c
>  * Performing LDAP DSE lookup on: 1d.e.f.g
>  * Successfully discovered: domain
> Password for me@DOMAIN: ***
> * Unconditionally checking packages
>  * Resolving required packages
>  [...]
>  * Generated 120 character computer password
>  * Using keytab: FILE:/etc/krb5.keytab
>  * Found computer account for COMPUTER
>  * Set computer password
>  * Retrieved kvno '14' for computer account in directory: ...
>   * Modifying computer account: userAccountControl
>  * Modifying computer account: operatingSystemVersion,
> operatingSystemServicePack
>  * Modifying computer account: userPrincipalName
>  * Cleared old entries from keytab: FILE:/etc/krb5.keytab
>  * Discovered which keytab salt to use
>  * Added the entries to the keytab: ...
>  * /usr/sbin/update-rc.d sssd enable
>  * /usr/sbin/service sssd restart
>  * Successfully enrolled machine in realm
> ===
> 
> /etc/sssd/sssd.conf
> 
> [sssd]
> domains = domain
> config_file_version = 2
> services = nss, pam, ifp # added ifp
> 
> [domain/domain]
> ad_domain = domain
> krb5_realm = DOMAIN
> 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 = True
> fallback_homedir = /home/%u@%d
> access_provider = ad
> ===
> 
> klist shows a valid ticket and everything seemed to be working.
> 
> 
> But when I was trying to login (yes, I made sure that my time is synced
> and I made sure /etc/nssswitch.conf was correct) with my "me@domain"
> login it never worked. I tried also id me@domain and sssctl (had to add
> ifp, seems like realm doesn't add) but it wasn't working for my login.
> 
> After trying a lot of different combinations with different id,
> auth_providers and ldap I discovered that the AD Server is setup
> in such a way (probably due to DSVGO) that the Domain-PC Accounts
> are not allowed to read from the OU where all the staff users are
> placed. And indeed, when I copied the exact search query from the
> sssd_domain log with debug-level 7 and instructed
> ldapsearch to use GSSAPI with the Domain-PC ticket I always got a
> "not found". However, when I used simple bind with "me@domain" +
> password auth I got the request worked.
> 
> So, I wonder if it is possible to extend sssd in such a way that
> id lookups could be performed with the provided either a provided
> user secret instead of the machine secret?

Sorry, not right now. The AD provider presumes that a keytab is used.
But there's nothing saying that the keytab must contain a machine
account principal. I guess you could create a keytab for some user, even
the one you used for the simple bind authentication and then instruct
sssd with the help of ldap_sasl_authid to use your custom principal (by
default sssd tries to search for principal based on the host name).

btw as a coincidence, I was looking into extending the IPA provider (which
has pretty much the same issues as the AD provider) so that a client
side certificate could be used. So in future this might also be
possible, but not right now..
___
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: 

[SSSD-users] Re: Max hostname len in adcli or realm join to AD?

[Jakub Hrozek]

On Fri, Jul 19, 2019 at 11:43:37AM -0500, Spike White wrote:
> All,
> 
> In previous AD integration tools, the max host name length was customarily
> 15 chars.  Because of ancient NETBIOS restrictions (16 char restrictions
> and netbios adds a '$' to the end of host name).
> 
> That was like an AD 2003 restriction.
> 
> With some slightly (well-documented) trickiness, in newer AD deployments
> those AD integration tools would allow up to an 18 char host name.
> 
> I see in modern AD now, up to a 20 character name is tolerated (although
> recommendation is to retain the final '$').  So -- 19 char max.
> 
> https://social.technet.microsoft.com/Forums/en-US/f2afb2ce-74fb-4434-932b-6b71c3654a98/ad-computer-names-over-15-characters?forum=winserverDS
> 
> 
> (However, that statement that 'common name' (max length 15) has to be
> unique in the OU is troubling. If you put all your Linux servers in the
> same OU, you're back to your 15 char limitation.)
> 
> Apparently, in 2013 realm join and adcli allowed a15 char host name max.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1001667
> 
> Is that still true today, max 15 char host name in realm join / adcli?
> 
> Spike

A cursory look at adcli source code says it is:

 241 »···if (strlen (computer_name) > 15) {
 242 »···»···computer_name[15] = 0;
 243 »···»···_adcli_info ("Truncated computer account name from fqdn: 
%s", computer_name);
 244 »···} else {
 245 »···»···_adcli_info ("Calculated computer account name from fqdn: 
%s", computer_name);
 246 »···}
___
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: sssd_be core dumping when ‘realm permit’ command run under puppet control…

[Jakub Hrozek]

On Tue, Jul 16, 2019 at 12:32:29PM -0500, Spike White wrote:
> The following case has been opened with RHEL support on this.  It was
> opened this morning:
> 
> (SEV 4) Case #02427449 ('realm permit group@DOMAIN' causing background
> process sssd_be to segfault.)

Thank you, comment added. I hope a BZ would be created soon.
___
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: Replicate digest mapping from pam_pkcs11

[Jakub Hrozek]

rhank you; comment added. so hopefully the case would turn into a bug
report.

(This still does not mean the digest matching would be implemented, but
it's the best way I can think of to track a missing functionality..)

On Mon, Jul 15, 2019 at 08:27:08PM -, James Trater wrote:
> Thank you. I have opened case # 02426830 with Red Hat support.
> 
> > 
> > In the meantime I would suggest to file a bug against SSSD either in the
> > upstream tracker, or, since you said RHEL removal also affects you, a RH
> > support case (feel free to send me the case number, then).
> > 
> ___
> 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 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: sssd_be core dumping when ‘realm permit’ command run under puppet control…

[Jakub Hrozek]

On Mon, Jul 15, 2019 at 12:50:03PM -0500, Spike White wrote:
> All,
> 
> This is a strange one.  When we exec this command under puppet control:
> 
> /usr/sbin/realm permit -R AMER.COMPANY.COM
> processehcprofi...@amer.company.com
> 
> Then sssd_be core dumps (segfault).

Anytime sssd_be segfaults, it is a bug. Could you file a bug or a
support case (since you mentioned RHEL). In case you file a support
case, feel free to send me the number so we can follow up.

It would be nice to attach the core and logs etc to the case or the bug,
because our tests make use of realm permit and we have not hit the bug
so far.

> 
> When we run that ‘realm permit’ command natively on the command line, it
> executes flawlessly.  No core dump.
> 
> Naturally, our first thought was that it’s something different in the
> environment.  So we dumped the environment under which puppet exec resource
> runs.
> 
> Yes, quite minimal.
> 
> LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.m4a=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.oga=01;36:*.opus=01;36:*.spx=01;36:*.xspf=01;36:
> 
> LD_LIBRARY_PATH=
> 
> LANG=en_US.UTF-8
> 
> HISTCONTROL=ignoredups
> 
> HOSTNAME=austgcore25.us.company.com
> 
> S_COLORS=auto
> 
> PWD=/root
> 
> APT_LISTCHANGES_FRONTEND=none
> 
> DEBIAN_FRONTEND=noninteractive
> 
> APT_LISTBUGS_FRONTEND=none
> 
> MAIL=/var/spool/mail/root
> 
> SHELL=/bin/bash
> 
> TERM=xterm
> 
> SHLVL=2
> 
> MANPATH=:/opt/puppetlabs/puppet/share/man
> 
> PATH=/bin:/usr/bin:/sbin:/usr/sbin
> 
> HISTSIZE=1000
> 
> LESSOPEN=||/usr/bin/lesspipe.sh %s
> 
> _=/bin/env
> 
> 
> 
> But when we create a bash session with no environment, then add this
> puppet-supplied environment and run the above realm permit– all is still
> well.
> 
> We can reproduce this easily in puppet.  Just delete our breadcrumb file
> (so that puppet re-executes this ‘realm permit’ command). And execute
> another puppet agent run.
> 
> Doing this, we obtained a core dump from sssd_be.  And it points to some
> code in ad_id.c:
> 
> [root@austgcore25 tmp]# gdb -c
> core-sssd_be.15405.austgcore25.us.company.com.1563210863
> 
> GNU gdb (GDB) Red Hat Enterprise Linux 8.2-5.el8
> 
> Copyright (C) 2018 Free Software Foundation, Inc.
> 
> License GPLv3+: GNU GPL version 3 or later  >
> 
> This is free software: you are free to change and redistribute it.
> 
> There is NO WARRANTY, to the extent permitted by law.
> 
> Type "show copying" and "show warranty" for details.
> 
> This GDB was configured as "x86_64-redhat-linux-gnu".
> 
> Type "show configuration" for configuration details.
> 
> For bug reporting instructions, please see:
> 
> .
> 
> Find the GDB manual and other documentation resources online at:
> 
> .
> 
> 
> 
> For help, type "help".
> 
> Type "apropos word" to search for commands related to "word".
> 
> [New LWP 15405]
> 
> Reading symbols from /usr/libexec/sssd/sssd_be...Reading symbols from
> /usr/lib/debug/usr/libexec/sssd/sssd_be-2.0.0-43.el8.x86_64.debug...done.
> 
> done.
> 
> 
> 
> warning: Ignoring non-absolute filename: 
> 
> Missing separate debuginfo for linux-vdso.so.1
> 
> Try: dnf --enablerepo='*debug*' install
> /usr/lib/debug/.build-id/06/44254f9cbaa826db070a796046026adba58266
> 
> 
> 
> warning: .dynamic section for "/usr/lib64/libndr-nbt.so.0.0.1" is not at
> the expected address (wrong library or version mismatch?)
> 
> [Thread debugging using libthread_db enabled]
> 
> Using host libthread_db library "/lib64/libthread_db.so.1".
> 
> Core was generated by 

[SSSD-users] Re: Replicate digest mapping from pam_pkcs11

[Jakub Hrozek]

On Mon, Jul 15, 2019 at 02:49:19PM -, James Trater wrote:
> Hello.
> 
> Is it possible to replicate the digest mapping feature of pam_pkcs11
> in sssd? We have built our infrastructure around the notion of mapping
> users to certificates based on the certificate digest. With the removal
> of pam_pkcs11 from recent distros (including RHEL 8) we are faced with
> either changing our mapping scheme (potentially a lot of work) or making
> this work in sssd. This is a snippet of what we do today:

Sumit, who primarily develops anything related to smart cards is on
vacation and will be for another two weeks.

In the meantime I would suggest to file a bug against SSSD either in the
upstream tracker, or, since you said RHEL removal also affects you, a RH
support case (feel free to send me the case number, then).

> 
> --- snip pam_pkcs11.conf ---
>   # digest - elaborate certificate digest and map it into a file
>   mapper digest {
> debug = false;
> module = internal;
> # module = /usr/$LIB/pam_pkcs11/digest_mapper.so;
> # algorithm used to evaluate certificate digest
> # Select one of:
> # "null","md2","md4","md5","sha","sha1","dss","dss1","ripemd160"
> algorithm = "sha1";
> mapfile = file:///etc/pam_pkcs11/digest_mapping;
> # mapfile = "none";
>   }
> --- snip ---
> 
> 
> # snippet of digest_mapping file  (the values have been obfuscated)
> 
> [root@friday-vm]# grep jim digest_mapping
> 
> 11:BC:53:F1:EF:24:B4:9C:47:ED:7D:EC:2B:82:CB:93:61:F8:88:4F -> jim
>  
> ___
> 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 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: sssd sudo using Microsoft Active Directory

[Jakub Hrozek]

On Mon, Jul 01, 2019 at 09:09:24AM -, B M wrote:
> Hi Jakub, 
> 
> Thx for the suggestions!
> 
> Here more logs:
> 
> NOTE: Replaced - or  from the original name.
> 
> /var/log/sssd/sssd_sudo.log
> 
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [accept_fd_handler] (0x0400): Client 
> connected!
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [sss_cmd_get_version] (0x0200): 
> Received client version [1].
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [sss_cmd_get_version] (0x0200): 
> Offered version [1].
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [sudosrv_cmd] (0x2000): Using 
> protocol version [1]
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [sudosrv_get_rules_send] (0x0400): 
> Running initgroups for [ad...@awsad.-.com]
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [cache_req_set_plugin] (0x2000): CR 
> #8: Setting "Initgroups by name" plugin
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [cache_req_send] (0x0400): CR #8: New 
> request 'Initgroups by name'
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [cache_req_process_input] (0x0400): 
> CR #8: Parsing input name [ad...@awsad.-.com]
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [sss_parse_name_for_domains] 
> (0x0200): name 'ad...@awsad.-.com' matched expression for domain 
> 'awsad.-.com', user is admin
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [cache_req_set_name] (0x0400): CR #8: 
> Setting name [admin]
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [cache_req_select_domains] (0x0400): 
> CR #8: Performing a single domain search
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [sss_domain_get_state] (0x1000): 
> Domain awsad.-.com is Active
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [cache_req_search_domains] (0x0400): 
> CR #8: Search will check the cache and check the data provider
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [cache_req_validate_domain_type] 
> (0x2000): Request type POSIX-only for domain awsad.-.com type POSIX 
> is valid
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [cache_req_set_domain] (0x0400): CR 
> #8: Using domain [awsad.-.com]
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [cache_req_prepare_domain_data] 
> (0x0400): CR #8: Preparing input data for domain [awsad.-.com] rules
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [cache_req_search_send] (0x0400): CR 
> #8: Looking up ad...@awsad.-.com
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [cache_req_search_ncache] (0x0400): 
> CR #8: Checking negative cache for [ad...@awsad.-.com]
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [sss_ncache_check_str] (0x2000): 
> Checking negative cache for 
> [NCE/USER/awsad.-.com/ad...@awsad.-.com]
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [cache_req_search_ncache] (0x0400): 
> CR #8: [ad...@awsad.-.com] is not present in negative cache
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [cache_req_search_cache] (0x0400): CR 
> #8: Looking up [ad...@awsad.-.com] in cache
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [cache_req_search_send] (0x0400): CR 
> #8: Object found, but needs to be refreshed.
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [cache_req_search_dp] (0x0400): CR 
> #8: Looking up [ad...@awsad.-.com] in data provider
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [sss_dp_issue_request] (0x0400): 
> Issuing request for 
> [0x55c2341d5360:3:ad...@awsad.-.com@awsad.-.com]
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [sss_dp_get_account_msg] (0x0400): 
> Creating request for 
> [awsad.-.com][0x3][BE_REQ_INITGROUPS][name=ad...@awsad.-.com:-]
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [sbus_add_timeout] (0x2000): 
> 0x55c2362f3a70
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [sss_dp_internal_get_send] (0x0400): 
> Entering request 
> [0x55c2341d5360:3:ad...@awsad.-.com@awsad.-.com]
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [sbus_remove_timeout] (0x2000): 
> 0x55c2362f3a70
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [sss_dp_get_reply] (0x0010): The Data 
> Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline]

You'll want to fix this first..unless sssd can stay online at least for
the duration of the test, the logs won't be as useful..

The way I usually debug these issues is to find the first occurence of
"Going offline" or "Marking port XYZ as NOT_WORKING" in the log and then
look couple of lines before.

See inline..

> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [cache_req_common_dp_recv] (0x0040): 
> CR #8: Data Provider Error: 3, 5, Failed to get reply from Data Provider
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [cache_req_common_dp_recv] (0x0400): 
> CR #8: Due to an error we will return cached data
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [cache_req_search_cache] (0x0400): CR 
> #8: Looking up [ad...@awsad.-.com] in cache
> (Mon Jul  1 08:25:02 2019) [sssd[sudo]] [cache_req_search_ncache_filter] 
> (0x0400): CR #8: This request type does not support filtering result by 
> negative cache
> (Mon Jul  1 08:25:02 

[SSSD-users] Re: sssd sudo using Microsoft Active Directory

[Jakub Hrozek]

On Sun, Jun 30, 2019 at 09:31:17AM -, Bruno Monteiro wrote:
> Hello,
> 
> Below my configuration and errors :)
> 
> (I've adapted some strings for the sake of example - domain is not real)
> 
> cat /etc/sssd/sssd.conf
> [sssd]
> services = nss, pam,ssh, sudo
> debug_level = 0x7FFF
> domains = LDAP_MY.COM
> 
> [sudo]
> debug_level = 0x3ff0
> 
> [domain/LDAP_MY.COM]
> debug_level = 0x3ff0
> access_provider = ldap
> id_provider = ldap
> sudo_provider = ldap
> ldap_uri = ldap://
> ldap_default_bind_dn = @my.com
> ldap_default_authtok = 
> ldap_sudo_search_base = OU=SUDOers,DC=my,DC=com
> 
> /etc/nsswitch.conf
> ...
> sudoers:sss files
> 
> 
> 
> ldbsearch -H /var/lib/sss/db/cache_LDAP_MY.COM/ldb contains Microsoft AD 
> records:
> 
> # record 2
> dn: name=r2,cn=sudorules,cn=custom,cn=LDAP_MY.COM,cn=sysdb

the config snippet says the sudo search base is ou=sudoers, but the rule
example is at cn=sudoers,cn=custom..

> cn: r2
> dataExpireTimestamp: 1561891358
> entryUSN: 245385
> name: r2
> objectClass: sudoRule
> originalDN: CN=r2,OU=SUDOers,DC=my,DC=com
> sudoCommand: ALL
> sudoHost: ALL
> sudoOption: !authenticate
> sudoUser: ad...@my.com
> distinguishedName: name=r2,cn=sudorules,cn=custom,cn=LDAP_MY.COM,
>  cn=sysdb
> 
> AD sudoRole is sudoRule in local SSSD DB cache.
> 
> 
> But getting this below when trying to test 'sudo -l' or 'sudo su'
> 
> [sssd[sudo]] [sudosrv_fetch_rules] (0x0400): Returning 0 rules for 
> [ad...@my.com@my.com] 
> 
> from /var/log/sssd/sssd_sudo.log 
> 
> Duplicate domain ?

That's just a minor bug in the debug message (at one point we switched
to using qualified names everywhere internally, but some debug messages
were qualifying the names on their own..)

> 
> I can see the rules been updated in the SSSD cache file from Microsoft AD.
> 
> But I cannot use them because maybe some misconfiguration ?

You're using the plain ldap sudo provider, but you're not using
case_sensitive=false so you need to make sure the case matches exactly;
AD is case-insensitive, but Linux is case-sensitive.

Also, I'm not sure if the plain LDAP provider is able to match the name
qualified with the domain name (ad...@my.com) in sudoUser or only username
(Admin).

Posting more context from the logs might be helpful as well.

> 
> setup for sudo logs:
> /etc/sudo.conf and put down the following lines:
> Debug sudo /var/log/sudo_debug all@debug
> Debug sudoers.so /var/log/sudo_debug all@debug
> 
> from /var/log/sudo_debug I have this:
> ...
> user_in_group: user ad...@my.com NOT in group sudo
> ...
> 
> Thx a lot!
> 
> Cheers!
> ___
> 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 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: id / getent not finding AD users

[Jakub Hrozek]

On Thu, Jun 27, 2019 at 05:01:27PM +, Thomas Beaudry wrote:
> Hi Jakub,
> 
> So i tired 
> 
> >> Does it help to increase the dns_resolver_timeout from its default of 6
> seconds? Please see the note in man sssd-ad, there are several timeouts
> that might need to be increased in unison, can you try e.g.:
> ldap_opt_timeout = 20
> dns_resolver_timeout = 10
> 
> but it didn't fix the problem.  Here is my domain log with the same 
> timesteamp as my id  command:  https://pastebin.com/raw/swicNUPe
> 
> thanks,
> Thomas

OK, but now the error is different, right? At least in the domain log I
see:
(Thu Jun 27 12:56:09 2019) [sssd[be[MYDOMAIN.ca]]] [sdap_get_tgt_recv] 
(0x0400): Child responded: 14 [Client not found in Kerberos database], expired 
on [0]

btw I find it odd that the logs seemingly uses the host/hostname
principal:
(Thu Jun 27 12:56:03 2019) [sssd[be[MYDOMAIN.ca]]] [sdap_kinit_send]
(0x0400): Attempting kinit (default, host/perform-capstone, MYDOMAIN.ca,
86400)

did you specify ldap_sasl_authid yourself or did sssd pick this
principal? If sssd did pick this principal, can I see the whole log?
___
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: id / getent not finding AD users

[Jakub Hrozek]

On Tue, Jun 25, 2019 at 08:25:44PM +, Thomas Beaudry wrote:
> Hi again,
> 
> Okay so i look at my sssd_MYDOMAIN log i get:
> 
> (Tue Jun 25 16:17:17 2019) [sssd[be[MYDOMAIN.ca]]] [request_watch_destructor] 
> (0x0400): Deleting request watch
> (Tue Jun 25 16:17:17 2019) [sssd[be[MYDOMAIN.ca]]] [fo_discover_srv_done] 
> (0x0400): Got answer. Processing...
> (Tue Jun 25 16:17:17 2019) [sssd[be[MYDOMAIN.ca]]] [fo_discover_srv_done] 
> (0x0400): Got 5 servers
> (Tue Jun 25 16:17:17 2019) [sssd[be[MYDOMAIN.ca]]] [ad_get_dc_servers_done] 
> (0x0400): Found 5 domain controllers in domain MYDOMAIN.ca
> (Tue Jun 25 16:17:17 2019) [sssd[be[MYDOMAIN.ca]]] [ad_srv_plugin_dcs_done] 
> (0x0400): About to locate suitable site
> (Tue Jun 25 16:17:17 2019) [sssd[be[MYDOMAIN.ca]]] [sdap_connect_host_send] 
> (0x0400): Resolving host dc.MYDOMAIN.ca
> (Tue Jun 25 16:17:17 2019) [sssd[be[MYDOMAIN.ca]]] 
> [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 
> 'dc.MYDOMAIN.ca' in files
> (Tue Jun 25 16:17:17 2019) [sssd[be[MYDOMAIN.ca]]] 
> [resolv_gethostbyname_files_send] (0x0100): Trying to resolve  record of 
> 'dc.MYDOMAIN.ca' in files
> (Tue Jun 25 16:17:17 2019) [sssd[be[MYDOMAIN.ca]]] 
> [resolv_gethostbyname_next] (0x0200): No more address families to retry
> (Tue Jun 25 16:17:17 2019) [sssd[be[MYDOMAIN.ca]]] 
> [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 
> 'dc.MYDOMAIN.ca' in DNS

Looks like it took 2 seconds here to resolve a DNS record..

> (Tue Jun 25 16:17:19 2019) [sssd[be[MYDOMAIN.ca]]] [request_watch_destructor] 
> (0x0400): Deleting request watch
> (Tue Jun 25 16:17:19 2019) [sssd[be[MYDOMAIN.ca]]] 
> [sdap_connect_host_resolv_done] (0x0400): Connecting to 
> ldap://dc.MYDOMAIN.ca:389
> (Tue Jun 25 16:17:19 2019) [sssd[be[MYDOMAIN.ca]]] [sss_ldap_init_send] 
> (0x0400): Setting 6 seconds timeout for connecting
> (Tue Jun 25 16:17:19 2019) [sssd[be[MYDOMAIN.ca]]] [sdap_connect_host_done] 
> (0x0400): Successful connection to ldap://dc.MYDOMAIN.ca:389
> (Tue Jun 25 16:17:19 2019) [sssd[be[MYDOMAIN.ca]]] 
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with 
> [(&(DnsDomain=MYDOMAIN.ca)(NtVer=\14\00\00\00))][].
> (Tue Jun 25 16:17:19 2019) [sssd[be[MYDOMAIN.ca]]] 
> [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg 
> set
> (Tue Jun 25 16:17:19 2019) [sssd[be[MYDOMAIN.ca]]] [ad_get_client_site_done] 
> (0x0400): Found site: Default-First-Site-Name
> (Tue Jun 25 16:17:19 2019) [sssd[be[MYDOMAIN.ca]]] [ad_srv_plugin_site_done] 
> (0x0400): About to discover primary and backup servers
> (Tue Jun 25 16:17:19 2019) [sssd[be[MYDOMAIN.ca]]] [fo_discover_servers_send] 
> (0x0400): Looking up primary servers
> (Tue Jun 25 16:17:19 2019) [sssd[be[MYDOMAIN.ca]]] 
> [resolv_discover_srv_next_domain] (0x0400): SRV resolution of service 'ldap'. 
> Will use DNS discovery domain 'Default-First-Site-Name._sites.MYDOMAIN.ca'
> (Tue Jun 25 16:17:19 2019) [sssd[be[MYDOMAIN.ca]]] [resolv_getsrv_send] 
> (0x0100): Trying to resolve SRV record of 
> '_ldap._tcp.Default-First-Site-Name._sites.MYDOMAIN.ca'

..and then another 2 seconds here, which caused a timeout in the server
discovery.

Does it help to increase the dns_resolver_timeout from its default of 6
seconds? Please see the note in man sssd-ad, there are several timeouts
that might need to be increased in unison, can you try e.g.:
ldap_opt_timeout = 20
dns_resolver_timeout = 10

(This might even be too high, but let's see..)

> (Tue Jun 25 16:17:21 2019) [sssd[be[MYDOMAIN.ca]]] 
> [fo_resolve_service_timeout] (0x0080): Service resolving timeout reached
> (Tue Jun 25 16:17:21 2019) [sssd[be[MYDOMAIN.ca]]] [request_watch_destructor] 
> (0x0400): Deleting request watch
> (Tue Jun 25 16:17:21 2019) [sssd[be[MYDOMAIN.ca]]] [sdap_id_op_connect_done] 
> (0x0020): Failed to connect, going offline (5 [Input/output error]
> 
> 
> Thanks!
> Thomas
> 
> From: Jakub Hrozek 
> Sent: Tuesday, June 25, 2019 3:56 PM
> To: sssd-users@lists.fedorahosted.org
> Subject: [SSSD-users] Re: id / getent not finding AD users
> 
> On Tue, Jun 25, 2019 at 07:25:45PM +, Thomas Beaudry wrote:
> > Hi Jakub,
> >
> > Thanks for the link so i followed the troubleshooting and I notice i can't 
> > reach the data provider mentioned in step 4 ("If the command is reaching 
> > the NSS responder, does it get forwarded to the Data Provider?")
> >
> >
> > If i look at my sssd_nss log i get with a timestamp that matches my id 
> >  command:
> >
> > (Tue Jun 25 15:14:16 2019) [sssd[nss]] [sss_parse_name_for_domains] 
> > (0x0200): name 'root' matched without domain, user i

[SSSD-users] Re: id / getent not finding AD users

[Jakub Hrozek]

On Tue, Jun 25, 2019 at 07:25:45PM +, Thomas Beaudry wrote:
> Hi Jakub,
> 
> Thanks for the link so i followed the troubleshooting and I notice i can't 
> reach the data provider mentioned in step 4 ("If the command is reaching the 
> NSS responder, does it get forwarded to the Data Provider?")
> 
> 
> If i look at my sssd_nss log i get with a timestamp that matches my id 
>  command:
> 
> (Tue Jun 25 15:14:16 2019) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): 
> name 'root' matched without domain, user is root
> (Tue Jun 25 15:14:16 2019) [sssd[nss]] [sss_ncache_set_str] (0x0400): Adding 
> [NCE/USER/MYDOMAIN.ca/root] to negative cache permanently
> (Tue Jun 25 15:14:16 2019) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): 
> name 'root' matched without domain, user is root
> (Tue Jun 25 15:14:16 2019) [sssd[nss]] [sss_ncache_set_str] (0x0400): Adding 
> [NCE/GROUP/MYDOMAIN.ca/root] to negative cache permanently
> (Tue Jun 25 15:14:16 2019) [sssd[nss]] [sss_dp_req_destructor] (0x0400): 
> Deleting request: [0x41eb90:doma...@mydomain.ca]
> (Tue Jun 25 15:14:41 2019) [sssd[nss]] [accept_fd_handler] (0x0400): Client 
> connected!
> (Tue Jun 25 15:14:41 2019) [sssd[nss]] [sss_cmd_get_version] (0x0200): 
> Received client version [1].
> (Tue Jun 25 15:14:41 2019) [sssd[nss]] [sss_cmd_get_version] (0x0200): 
> Offered version [1].
> (Tue Jun 25 15:14:41 2019) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running 
> command [17][SSS_NSS_GETPWNAM] with input [admin].
> (Tue Jun 25 15:14:41 2019) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): 
> name 'admin' matched without domain, user is admin
> (Tue Jun 25 15:14:41 2019) [sssd[nss]] [nss_cmd_getbynam] (0x0100): 
> Requesting info for [admin] from []
> (Tue Jun 25 15:14:41 2019) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): 
> Requesting info for [ad...@mydomain.ca]
> (Tue Jun 25 15:14:41 2019) [sssd[nss]] [get_dp_name_and_id] (0x0400): Not a 
> LOCAL view, continuing with provided values.
> (Tue Jun 25 15:14:41 2019) [sssd[nss]] [sss_dp_issue_request] (0x0400): 
> Issuing request for [0x41d420:1:ad...@mydomain.ca]
> (Tue Jun 25 15:14:41 2019) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): 
> Creating request for [MYDOMAIN.ca][0x1001][FAST BE_REQ_USER][1][name=admin]

The request gets forwarded to the data provider here..

> (Tue Jun 25 15:14:41 2019) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): 
> Entering request [0x41d420:1:ad...@mydomain.ca]
> (Tue Jun 25 15:14:41 2019) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): 
> Unable to get information from Data Provider
> Error: 1, 11, Fast reply - offline

..but the data provider replies immediately because it had switched to
the offline mode. For one reason or another, sssd_be couldn't reach any
of the configured or auto-discovered servers.

> (Tue Jun 25 15:14:41 2019) [sssd[nss]] [sss_dp_req_destructor] (0x0400): 
> Deleting request: [0x41d420:1:ad...@mydomain.ca]
> (Tue Jun 25 15:14:41 2019) [sssd[nss]] [client_recv] (0x0200): Client 
> disconnected!
> 
> 
> What would be the next step?

I would suggest looking at the sssd_MYDOMAIN.log files and look for
messages that contain strings like "marking server XYZ as NOT_WORKING"
or "Going offline". Then look for the request a little earlier, that's
what causes sssd to go offline.
___
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: sssd with samba

[Jakub Hrozek]

On Wed, Jun 19, 2019 at 01:57:59PM -0300, Edouard Guigné wrote:
> Dear sssd users,
> 
> I would like to get informations about the use of sssd with samba (centos 7,
> samba 4.8.3).
> 
> I need it because I configured a samba share, accessible with sssd.
> The authentication is against a windows AD.
> 
> My /etc/nsswitch.cnf is configured only with sssd :
> /passwd: files sss//
> //shadow: files sss//
> //group:  files sss/
> 
> For an other purpose, I set an  sftpd access also configured with sssd
> against the AD.
> 
> I followed some discussions on the samba user list about samba + sssd.
> I would like to understand if there are some issues with sssd and samba
> 4.8.3 on centos 7 ?
> Or is it with next RHEL 8 ?
> 
> /The RHEL 8 documentation states this: //
> 
> //"Red Hat only supports running Samba as a server with the winbindd //
> //service to provide domain users and groups to the local system. Due to //
> //certain limitations, such as missing Windows access control list (ACL) //
> //support and NT LAN Manager (NTLM) fallback, SSSD is not supported." //
> 
> //https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/assembly_using-samba-as-a-server_deploying-different-types-of-servers
> 
> //What's confusing is that the RHEL 7 documentation says: //
> 
> //"Prior to Red Hat Enterprise Linux 7.1, only Winbind provided this //
> //functionality. In Red Hat Enterprise Linux 7.1 and later, you no longer //
> //need to run Winbind and SSSD in parallel to access SMB shares. For //
> //example, accessing the Access Control Lists (ACLs) no longer requires //
> //Winbind on SSSD clients." //
> 
> //and //
> 
> //"4.2.2. Determining Whether to Use SSSD or Winbind for SMB Shares //
> //For most SSSD clients, using SSSD is recommended:" //
> 
> //and most worrisome, in my use case: //
> 
> //"In environments with direct Active Directory integration where the //
> //clients use SSSD for general Active Directory user mappings, using //
> //Winbind for the SMB ID mapping instead of SSSD can result in //
> //inconsistent mapping."
> /
> 
> In my case, running samba 4.8.3 with SSSD on centos 7 do I need to :

I'm not an expert in this are, but look at some threads in the list
archive e.g. this one:

https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/thread/U66MEJBMXVJWJVCBORS2KBP7BIAGZ57H/
even has a full example.

> - enable and start winbind service , in conjunction to sssd ?

Yes, that's my understanding with recent Samba releases

> - or only sssd is enough with samba ?
> - Do I have to fear issues in next release of sssd for the support of samba
> ? especially for acls support ?/
> /
> 
> A nsswitch.conf like :
> passwd: files sss winbind
> shadow: files sss winbind
> group:  files sss winbind

..but I don't think you need the NSS maps enabled, IIRC just the service
must be running..

> 
> or
> 
> passwd: files winbind sss
> shadow: files winbind sss
> group:  files winbind sss
> 
> Does not seem to work... I test and this is not stable.
> 
> Best Regards,
> Edouard
> 

> ___
> 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 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: id / getent not finding AD users

[Jakub Hrozek]

On Tue, Jun 18, 2019 at 06:57:14PM +, Thomas Beaudry wrote:
> Hi Guys,
> 
> 
> i have 2 Ubuntu 16.04 servers that have their users run by AD.  The sssd.conf 
> and output of "realm list" is identical for both servers.  However, one of 
> them can't seem to find the AD users, so ssh fails.  I tried doing id   
> and getent passwd   and it doesn't find them.
> 
> 
> Do you know what the issue might be?

Not without logs, see:
https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html

> 
> 
> Thanks,
> 
> Thomas
> 
> 
> Here is my sssd.conf:
> 
> 
> # cat /etc/sssd/sssd.conf
> [autofs]
> debug_level=1
> 
> [krb5]
> debug_level=1
> 
> [nss]
> filter_groups = root
> filter_users = root
> reconnection_retries = 3
> 
> [pam]
> reconnection_retries = 3
> debug_level=1
> 
> [sssd]
> domains = MYDOMAIN.ca
> config_file_version = 2
> services = nss, pam, ssh, autofs
> debug_level=1
> 
> [domain/MYDOMAIN.ca]
> ad_domain = MYDOMAIN.ca
> krb5_realm = MYDOMAIN.CA
> 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 = True
> override_homedir = /NAS/home/%u
> fallback_homedir = /home/%u
> access_provider = simple
> debug_level=1
> ignore_group_members=True
> simple_allow_groups = perform_hpc
> 
> 
> and output of realm list:
> 
> # realm list
> MYDOMAIN.ca
>   type: kerberos
>   realm-name: MYDOMAIN.CA
>   domain-name: MYDOMAIN?.ca
>   configured: kerberos-member
>   server-software: active-directory
>   client-software: sssd
>   required-package: sssd-tools
>   required-package: sssd
>   required-package: libnss-sss
>   required-package: libpam-sss
>   required-package: adcli
>   required-package: samba-common-bin
>   login-formats: %U
>   login-policy: allow-permitted-logins
>   permitted-logins:
>   permitted-groups:
> 
> 
> 
> 

> ___
> 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 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: Use local posix group with ad-users to allow login access

[Jakub Hrozek]

On Fri, Jun 14, 2019 at 09:22:17AM -, Mads Boye wrote:
> Hi Jakub.
> Thank you for the reply. I still have no success.
> 
> Did try the AllowGroup in sshd_config but with no luck.
> 
> So I did a bit more investigation on pam_access and think that pam_access and 
> pam_sss might be locking each other out.
> 
> So I will try to explain my setup.
> In sssd.conf we use the "simple_allow_groups" for access for users and admins.
> The config loooks like:
> /etc/sssd/sssd.conf:
> [sssd]
> services = nss, pam
> #debug_level = 9
> config_file_version = 2
> domains = example.dk
> default_domain_suffix = EXAMPLE.DK
> use_fully_qualified_names = TRUE
> 
> [autofs]
> 
> [nss]
> #debug_level = 9
> reconnection_retries = 3
> 
> [pam]
> #debug_level = 9
> reconnection_retries = 100
> # allow PAM to cache user details for this long
> # this can improve login times
> # but it also delays AD changes from being seen
> pam_id_timeout = 600
> 
> [domain/example.dk]
> id_provider = ad
> #debug_level = 6
> auth_provider = ad
> access_provider = simple
> ldap_id_mapping = False
> 
> simple_allow_groups = serveradm...@example.dk, hostacc...@example.dk
> chpass_provider = ad
> ad_gpo_access_control = disabled
> override_homedir = /user/%d/%u
> override_shell = /bin/bash
> dyndns_update = True
> dyndns_refresh_interval = 43200
> dyndns_update_ptr = True
> auto_private_groups = True
> 
> With this ssh and /bin/login works for members of AD groups.
> Now i have created a local group and added ad users to this
> sudo addgroup example
> sudo usermod -a -G example adu...@example.dk
> 
> adu...@example.dk is not member of the simple_allow_groups groups.
> Now i haved enabled pam_access.so in both /etc/pam.d/login and sshd
> 
> login (I have removed all comments, for readability):
> #
> # The PAM configuration file for the Shadow `login' service
> #
> auth   optional   pam_faildelay.so  delay=300
> auth [success=ok new_authtok_reqd=ok ignore=ignore user_unknown=bad 
> default=die] pam_securetty.so
> auth   requisite  pam_nologin.so
> 
> session [success=ok ignore=ignore module_unknown=ignore default=bad] 
> pam_selinux.so close
> sessionrequired pam_loginuid.so
> session   required   pam_env.so readenv=1
> session   required   pam_env.so readenv=1 envfile=/etc/default/locale
> 
> @include common-auth
> 
> auth   optional   pam_group.so
> account  required   pam_access.so
> sessionrequired   pam_limits.so
> sessionoptional   pam_lastlog.so
> sessionoptional   pam_motd.so motd=/run/motd.dynamic
> sessionoptional   pam_motd.so noupdate
> sessionoptional   pam_mail.so standard
> sessionoptional   pam_keyinit.so force revoke
> 
> @include common-account
> @include common-session
> @include common-password
> 
> sshd:
> # PAM configuration for the Secure Shell service
> @include common-auth
> accountrequired pam_nologin.so
> account  required pam_access.so
> @include common-account
> session [success=ok ignore=ignore module_unknown=ignore default=bad]
> pam_selinux.so close
> sessionrequired pam_loginuid.so
> sessionoptional pam_keyinit.so force revoke
> @include common-session
> sessionoptional pam_motd.so  motd=/run/motd.dynamic
> sessionoptional pam_motd.so noupdate
> sessionoptional pam_mail.so standard noenv # [1]
> sessionrequired pam_limits.so
> sessionrequired pam_env.so # [1]
> sessionrequired pam_env.so user_readenv=1 envfile=/etc/default/locale
> session [success=ok ignore=ignore module_unknown=ignore default=bad]
> pam_selinux.so open
> @include common-password
> 
> When i dug into auth.log it seemed like sssd authenticated the users, but 
> denied due to simple_allow_groups, so i changed 
> access_provider = simple to access_provider = permit and restarted sssd.
> 
> Now all users are allowed to login if AD autenticates them.
> Now i added the following to /etc/security/access.conf
> + : (example) : ALL
> - : ALL except root my-m...@example.dk : ALL
> 
> restarted sshd and sssd just to be sure.
> Now i get the following error
> Jun 14 10:47:37 example01 sshd[89937]: pam_unix(sshd:auth): authentication 
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.14.1.2  
> user=adu...@example.dk
> Jun 14 10:47:37 example01 sshd[89937]: pam_sss(sshd:auth): authentication 
> success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.14.1.2 
> user=adu...@example.dk
> Jun 14 10:47:37 example01 sshd[89937]: pam_access(sshd:account): access 
> denied for user `adu...@example.dk' from `10.14.1.2'
> Jun 14 10:47:37 example01 sshd[89937]: Failed password for adu...@example.dk 
> from 10.14.1.2 port 52944 ssh2
> Jun 14 10:47:37 example01 sshd[89937]: fatal: Access denied for user 
> adu...@example.dk by PAM account configuration [preauth]
> 
> If I change the "- : ALL except root my-m...@example.dk : ALL" to "- : ALL 
> except root EXAMPLE\aduser my-m...@example.dk : ALL"
> the aduser@example is 

[SSSD-users] Re: Announcing SSSD 2.2.0 (this time with the correct release notes)

[Jakub Hrozek]

tps://pagure.io/SSSD/sssd/issue/3964>`_ - Responders: 
`is_user_local_by_name()` should avoid calling nss API entirely
 * `3963 <https://pagure.io/SSSD/sssd/issue/3963>`_ - Responders: processing of 
`filter_users`/`filter_groups` should avoid calling blocking NSS API
 * `3960 <https://pagure.io/SSSD/sssd/issue/3960>`_ - cached_auth_timeout not 
honored for AD users authenticated via trust with FreeIPA
 * `3957 <https://pagure.io/SSSD/sssd/issue/3957>`_ - sudo: runAsUser/Group 
does not work with domain_resolution_order
 * `3946 <https://pagure.io/SSSD/sssd/issue/3946>`_ - SSSD netgroups do not 
honor entry_cache_nowait_percentage
 * `3931 <https://pagure.io/SSSD/sssd/issue/3931>`_ - proxy provider is not 
working with enumerate=true when trying to fetch all groups
 * `3907 <https://pagure.io/SSSD/sssd/issue/3907>`_ - responders chain requests 
that were issued before reconnection to sssd_be
 * `3899 <https://pagure.io/SSSD/sssd/issue/3899>`_ - change the default 
service search base in SSSD-IPA
 * `3867 <https://pagure.io/SSSD/sssd/issue/3867>`_ - [RFE] Need an option in 
SSSD so that it will skip GPOs that have groupPolicyContainers, unreadable by 
SSSD.
 * `3861 <https://pagure.io/SSSD/sssd/issue/3861>`_ - Python multihost tests 
are not part of upstream tarball
 * `3838 <https://pagure.io/SSSD/sssd/issue/3838>`_ - KCM: If the default 
ccache cannot be found, fall back to the first one
 * `3822 <https://pagure.io/SSSD/sssd/issue/3822>`_ - Enable generating user 
private groups only for users with no primary GID
 * `3769 <https://pagure.io/SSSD/sssd/issue/3769>`_ - sssd tools don't handle 
the implicit domain
 * `3636 <https://pagure.io/SSSD/sssd/issue/3636>`_ - nested group missing 
after updates on provider
 * `3614 <https://pagure.io/SSSD/sssd/issue/3614>`_ - FIPS mode breaks using 
pysss.so (sss_obfuscate)
 * `3467 <https://pagure.io/SSSD/sssd/issue/3467>`_ - online detection in case 
sssd starts before network does appears to be broken
 * `3401 <https://pagure.io/SSSD/sssd/issue/3401>`_ - sssd does not failover to 
another IPA server if just the KDC service fails
 * `3264 <https://pagure.io/SSSD/sssd/issue/3264>`_ - [RFE] Make 2FA prompting 
configurable
 * `1314 <https://pagure.io/SSSD/sssd/issue/1314>`_ - RFE Request for allowing 
password changes using SSSD in DS which dont follow OID's from RFC 3062

Detailed changelog
--

* Alexey Tikhonov (24): 

  * negcache: avoid "is_*_local" calls in some cases 
  * providers/ldap: sdap_extend_map_with_list() fixed 
  * providers/ldap: const params should be const 
  * providers/proxy: small optimization 
  * providers/proxy: fixed wrong check 
  * providers/proxy: fixed usage of wrong mem ctx 
  * providers/proxy: got rid of excessive mem copies 
  * providers/proxy: fixed erroneous free of orig_grp 
  * providers/proxy: const params should be const 
  * Util: added facility to load nss lib syms 
  * responder/negcache: avoid calling nsswitch NSS API 
  * negcache_files: got rid of large array on stack 
  * TESTS: moved cwrap/test_negcache to cmocka tests 
  * TESTS: fixed regression in cmocka/test_negcache_2.c 
  * ci/sssd.supp: getpwuid() leak suppression 
  * data_provider_be: fixed dereferencing of 'bad' ptr 
  * TESTS: two `negcache` tests were merged 
  * data_provider_be: got rid of went_offline usage 
  * providers/ipa: Fixed obvious copy-paste error 
  * providers/ipa: Changed default service search base 
  * TESTS: ability to run unit tests under valgrind 
  * Monitor & utils: got rid of pid filename duplication 
  * Monitor: fixed bug with services launch 
  * ldap/sdap_idmap.c: removed unnecessary include 

* Branen Salmon (1): 

  * knownhostsproxy: friendly error msg for NXDOMAIN 

* Colin Walters (1): 

  * sss_cache: Do nothing if SYSTEMD_OFFLINE=1 

* Jakub Hrozek (21): 

  * Updating the version to track the next release 
  * TESTS: Add a unit test for UPNs stored by sss_ncache_prepopulate 
  * UTIL: Add a is_domain_mpg shorthand 
  * UTIL: Convert bool mpg to an enum mpg_mode 
  * CONFDB: Read auto_private_groups as string, not bool 
  * CONFDB/SYSDB: Add the hybrid MPG mode 
  * CACHE_REQ: Add cache_req_data_get_type() 
  * NSS: Add the hybrid-MPG mode 
  * TESTS: Add integration tests for auto_private_groups=hybrid 
  * SYSDB: Inherit cached_auth_timeout from the main domain 
  * AD: Allow configuring auto_private_groups per subdomain or with 
subdomain_inherit 
  * SDAP: Add sdap_has_deref_support_ex() 
  * IPA: Use dereference for host groups even if the configuration disables 
dereference 
  * KCM: Fall back to using the first ccache if the default does not exist 
  * krb5: Do not use unindexed objectCategory in a search filter

[SSSD-users] Announcing SSSD 2.2.0

[Jakub Hrozek]

://pagure.io/SSSD/sssd/issue/3807 - The sbus codegen script relies
   on "python" which might not be available on all distributions

* There is a script that autogenerates code for the internal SSSD IPC.
  The script happens to call "python" which is not available on all
  distributions. Patching the ``sbus_generate.sh`` file to call e.g.
  python3 explicitly works around the issue

Tickets Fixed
-
 * `3717 <https://pagure.io/SSSD/sssd/issue/3717>`_ - Don't package 
sssd-secrets by default
 * `3685 <https://pagure.io/SSSD/sssd/issue/3685>`_ - KCM: Default to a new 
back end that would write to the secrets database directly
 * `3530 <https://pagure.io/SSSD/sssd/issue/3530>`_ - Remove 
CONFDB_DOMAIN_LEGACY_PASS
 * `3515 <https://pagure.io/SSSD/sssd/issue/3515>`_ - Disable host wildcards in 
sudoHost attribute (ldap_sudo_include_regexp=false)
 * `3494 <https://pagure.io/SSSD/sssd/issue/3494>`_ - Remove the special-case 
for RFC2307bis with zero nesting level
 * `3493 <https://pagure.io/SSSD/sssd/issue/3493>`_ - Remove the pysss.local 
interface
 * `3492 <https://pagure.io/SSSD/sssd/issue/3492>`_ - Remove support for 
ldap_groups_use_matching_rule_in_chain and 
ldap_initgroups_use_matching_rule_in_chain
 * `3304 <https://pagure.io/SSSD/sssd/issue/3304>`_ - Only build the local 
provider conditionally
 * `2926 <https://pagure.io/SSSD/sssd/issue/2926>`_ - Make list of local PAM 
services allowed for Smartcard authentication configurable

Detailed Changelog
--

* Amit Kumar (1): 

  * providers: disable ldap_sudo_include_regexp by default 

* Fabiano Fidêncio (19): 

  * man/sss_ssh_knownhostsproxy: fix typo pubkeys -> pubkey 
  * providers: drop ldap_{init,}groups_use_matching_rule_in_chain support 
  * ldap: remove parallel requests from rfc2307bis 
  * tests: adapt common_dom to files_provider 
  * tests: adapt test_sysdb_views to files provider 
  * tests: adapt sysdb-tests to files_provider 
  * tests: adapt sysdb_ssh tests to files provider 
  * tests: adapt auth-tests to files provider 
  * tests: adapt tests_fqnames to files provider 
  * sysdb: sanitize the dn on cleanup_dn_filter 
  * sysdb: pass subfilter and ts_subfilter to sysdb_search_*_by_timestamp() 
  * tests: adapt test_ldap_id_cleanup to files provider 
  * tests: remove LOCAL_SYSDB_FILE reference from test_sysdb_certmap 
  * tests: remove LOCAL_SYSDB_FILE reference from 
test_sysdb_domain_resolution_order_ 
  * tests: remove LOCAL_SYSDB_FILE reference from test_sysdb_subdomains 
  * tests: remove LOCAL_SYSDB_FILE reference from common_dom 
  * local: build local provider conditionally 
      * pysss: fix typo in comment 
  * pysss: remove pysss.local 

* Jakub Hrozek (55): 

  * Updating the version to track 1.16.4 development 
  * src/tests/python-test.py is GPLv3+ 
  * src/tests/intg/util.py is licensed under GPLv3+ 
  * src/tests/intg/test_ts_cache.py is licensed under GPLv3+ 
  * src/tests/intg/test_sudo.py is licensed under GPLv3+ 
  * src/tests/intg/test_sssctl.py is licensed under GPLv3+ 
  * src/tests/intg/test_ssh_pubkey.py is licensed under GPLv3+ 
  * src/tests/intg/test_session_recording.py is licensed under GPLv3+ 
  * src/tests/intg/test_secrets.py is licensed under GPLv3+ 
  * src/tests/intg/test_pysss_nss_idmap.py is licensed under GPLv3+ 
  * src/tests/intg/test_pam_responder.py is licensed under GPLv3+ 
  * src/tests/intg/test_pac_responder.py is licensed under GPLv3+ 
  * src/tests/intg/test_netgroup.py is licensed under GPLv3+ 
  * src/tests/intg/test_memory_cache.py is licensed under GPLv3+ 
  * src/tests/intg/test_local_domain.py is licensed under GPLv3+ 
  * src/tests/intg/test_ldap.py is licensed under GPLv3+ 
  * src/tests/intg/test_kcm.py is licensed under GPLv3+ 
  * src/tests/intg/test_infopipe.py is licensed under GPLv3+ 
  * src/tests/intg/test_files_provider.py is licensed under GPLv3+ 
  * src/tests/intg/test_files_ops.py is licensed under GPLv3+ 
  * src/tests/intg/test_enumeration.py is licensed under GPLv3+ 
  * src/tests/intg/sssd_passwd.py is licensed under GPLv3+ 
  * src/tests/intg/sssd_nss.py is licensed under GPLv3+ 
  * src/tests/intg/sssd_netgroup.py is licensed under GPLv3+ 
  * src/tests/intg/sssd_ldb.py is licensed under GPLv3+ 
  * src/tests/intg/sssd_id.py is licensed under GPLv3+ 
  * src/tests/intg/sssd_group.py is licensed under GPLv3+ 
  * src/tests/intg/secrets.py is licensed under GPLv3+ 
  * src/tests/intg/ldap_local_override_test.py is licensed under GPLv3+ 
  * src/tests/intg/ldap_ent.py is licensed under GPLv3+ 
  * src/tests/intg/krb5utils.py is licensed under GPLv3+ 
  * src/tests/intg/kdc.py is licensed under GPLv3+ 
  * src/tests/intg/files_ops.py is lice

[SSSD-users] Re: Use local posix group with ad-users to allow login access

[Jakub Hrozek]

On Thu, Jun 13, 2019 at 11:36:53AM -, Mads Boye wrote:
> Hi everyone.
> So I am banging my head against the wall and need some help.
> What i try to achive is having a local posix group, which contains active 
> directory users.
> Now i would like to use this posix group to allow the users to access the 
> server with e.g. ssh. How do I setup this?
> 
> Normally I use the allow_simple_groups for my AD user group who can login, 
> but hte documentation says that local groups are not evaluated.
> 
> I have tried with /etc/security/access.conf
> The OS I am using is Ubuntu 18.04

If you care only about sshd, then AllowGroups in sshd_config might be a
good option.

Otherwise pam_access and access.conf.. What did not work with
access.conf? Did you also make sure that pam_access is present in the
PAM stack?

> 
> Is what I am trying to achive possible with sssd?
> 
> Please let me know if additional information is needed.
> ___
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
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://getfedora.org/code-of-conduct.html
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: [alexander.fier...@mpi-dortmund.mpg.de: enumerate in sssd.conf]

[Jakub Hrozek]

On Wed, Jun 05, 2019 at 10:14:46AM +0200, Jakub Hrozek wrote:

> Date: Wed, 5 Jun 2019 10:04:56 +0200
> From: Alexander Fieroch 
> To: sssd-users-ow...@lists.fedorahosted.org
> Subject: enumerate in sssd.conf
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
>  Thunderbird/60.7.0
> 
> Hi,

Hi,

please note that the correct list for user facing questions is
sssd-users@lists.fedorahosted.org

> 
> I've set "enumerate = true" in sssd.conf which is working good for me and
> our AD clients.
> Now I recognized that RedHat does not recommend "enumerate = true" in
> sssd.conf:
> 
> <https://access.redhat.com/solutions/500433>
> 
> When I disable enumarate in sssd, "getent passwd" does not list AD users
> anymore. Is this normal behavior?

Yes, enumerate=true does two things:
 - in sssd_be, starts a periodical task that downloads all entries
   currently served by SSSD (users, groups, netgroups, services,
   ..)
- on the sssd_nss side, replies to getent passwd/getent group, or,
  on that level getpwent/getgrent/... with the contents of the
  cache.

> I use "getent passwd" for a quick test if sssd is working and finding AD
> users...

Yes, it's convenient, but fetching and saving all entries is also very
performance intensive, even with some optimizations like fetching only
delta since the previous lastUSN change. That's why it is not
recommended to use enumeration.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] [alexander.fier...@mpi-dortmund.mpg.de: enumerate in sssd.conf]

[Jakub Hrozek]

--- Begin Message ---

Hi,

I've set "enumerate = true" in sssd.conf which is working good for me 
and our AD clients.
Now I recognized that RedHat does not recommend "enumerate = true" in 
sssd.conf:




When I disable enumarate in sssd, "getent passwd" does not list AD users 
anymore. Is this normal behavior?
I use "getent passwd" for a quick test if sssd is working and finding AD 
users...


Best regards,
Alexander




smime.p7s
Description: S/MIME Cryptographic Signature
--- End Message ---
___
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://getfedora.org/code-of-conduct.html
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: Dynamic domain lookup

[Jakub Hrozek]

On Fri, May 31, 2019 at 10:10:12AM -0400, Nerigal wrote:
> Hi, 
> 
> Is it possible to make the domain section match the domain used by the
> user to authenticate using the re_expression =
> (?P[^@]+)@?(?P[^@]*$) 
> 
> So the domain section would look like 
> 
> [domain/$domain] 
> 
> ... 

I don't think so, why do you need this? The domains need to be hardcoded
anyway..
___
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://getfedora.org/code-of-conduct.html
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: Stupid question on ldap_user_email

[Jakub Hrozek]

On Tue, May 21, 2019 at 02:43:45PM +0100, John Hearns wrote:
> I have a test system which authenticates using sssd and an LDAP provider.
> So far so good!
> 
> In my LDAP object there is the field 'mail' which is my correct email
> address.
> I know I can get this using an ldapsearch.
> However I am asking if there is any clean and small utility which will
> print this out?
> I am asking as obviously scripts sometimes want to send email.
> 
> In sssd.conf there s the fieldldap_user_email
> How would this be queried?


Try:
dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe 
/org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserAttr 
string:$username array:string:mail

You need to have the [ifp] service enabled and call this this as a user
permitted in the ifp service's acls, see man sssd-ifp for some more
details.
___
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://getfedora.org/code-of-conduct.html
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: group memberships not updating

[Jakub Hrozek]

On Wed, May 15, 2019 at 12:33:33PM +0100, Toby Blake wrote:
> Hi,
> 
> We have noticed an issue where group memberships are not being updated
> on a significant number of our machines.
> 
> It appears that this has been reported in the following two bug reports:
> 
> https://pagure.io/SSSD/sssd/issue/3869
> https://pagure.io/SSSD/sssd/issue/3886
> 
> There hasn't been any activity on these for a few months now, so I thought
> I would add a me-too, and offer to do any debugging necessary.

I saw your comments, but I would even prefer if you either open a new
ticket first or add your debug logs here. "memberships not being
updated" is really too broad description to offer any help, sorry, we
need to see logs to see what is going on..
___
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://getfedora.org/code-of-conduct.html
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: authenticate linux using active directory without joined

[Jakub Hrozek]

On Sun, May 05, 2019 at 10:10:39AM +, Antonio Pena Diaz wrote:
> Hi,
> 
> 
> I need to connect by ssh using users centralized on AD, but linux servers 
> client use nslcd to retrieve the users settings and mapping attributes..
> 
> 
> I don't want to join linux servers into domain, and not use kerberos... exist 
> the possibility to do this with my settings nslcd ?
> 
> or how can I do same using sssd.conf to do it?

Maybe this could help?
https://docs.pagure.org/SSSD.sssd/users/ldap_with_ad.html

> 
> 
> using nscld, the only issue I have is, connecting by ssh  reach 
> authenticated but can't retrieve the shell and is mapped when get the entries 
> from active directory using ldap protocol.
> 
> 
> I'm not registered into list so please answer directly to my email.
> 
> 
> any idea?
> 
> 
> Thanks in advance.
> 
> 
> https://pastebin.com/1XmqF6LJ
> 
> [https://pastebin.com/i/facebook.png]
> 
> [root@centos-manager ~]# cat /etc/nslcd.conf uid nslcd gid ldap uri ldap:// - 
> Pastebin.com
> Altre info...
> 
> 
> 
> 
> 
> 
> 
> [APK]
> 
> 
> 
> Antonio Pena Diaz
> Sistemisti e Sistemi Informativi Interni
> Area Tecnica
> 
> APKAPPA s.r.l. sede legale Via F. Albani, 21 20149 Milano | p.iva/vat no. 
> IT-08543640158
> sede amministrativa e operativa Reggio Emilia (RE) via M. K. Gandhi, 24/ A 
> 42123 -  sede operativa Magenta (MI) via Milano 89/91 20013
> tel.  02 94454 000 | fax  02 94454 339 www.apkappa.it
> Seguici su:
> [Facebook] [LinkedIn] 
> 
> 
> 
> 
> 
> 
> Ai sensi e per gli effetti della Legge sulla tutela della riservatezza 
> personale (D.Lgs. 196/03 e collegate), questa mail è destinata unicamente 
> alle persone sopra indicate e le informazioni in essa contenute sono da 
> considerarsi strettamente riservate.
> This email is confidential, do not use the contents for any purpose 
> whatsoever nor disclose them to anyone else. If you are not the intended 
> recipient, you should not copy, modify, distribute or take any action in 
> reliance on it. If you have received this email in error, please notify the 
> sender and delete this email from your system.
> 




> ___
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
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://getfedora.org/code-of-conduct.html
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: pam_sssd: reset Samba4/AD password

[Jakub Hrozek]

On Tue, May 14, 2019 at 10:04:56AM +0200, Julien TEHERY wrote:
> Hi there
> 
> 
> We have a samba4 AD (installed on ubuntu servers) and also ubuntu client
> workstations.
> Those ubuntu workstations authenticate themselves to samba4/AD server
> through pam_sssd.
> 
> Users authentication against Samba4/AD works well, but i don't know how to
> allow users to change their own passwords through thios mecanism.
> I tried several methods like smbpasswd, samba-tool user setpassword, passwd
> or kpasswd but none of them works.

The only method out of those you listed above that goes through sssd is
plain 'passwd'. Did you have a chance to look into the logs? See
https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html
___
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://getfedora.org/code-of-conduct.html
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: RHEL8 sssd-kcm can't accept credentials forwarded from sshd?

[Jakub Hrozek]

On Fri, May 10, 2019 at 01:20:51PM -0400, James Ralston wrote:
> Now that RHEL8 is out, our site is again looking at whether it would
> be feasible to change our default Kerberos credentials storage from
> the kernel persistent keyring to sssd-kcm.

Which version is this? Is this RHEL-8 GA or one of the earlier
pre-release versions? Because the logs make it sound like
https://pagure.io/SSSD/sssd/issue/3873 which was fixed in time for
RHEL-8 GA.
___
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://getfedora.org/code-of-conduct.html
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: Local group and AD user mapping

[Jakub Hrozek]

On Sun, May 05, 2019 at 04:11:34PM -, soham chakraborty wrote:
> Hi,
> 
> I have a requirement where human users will be logging in with their AD 
> accounts. However, there are some applications that create local user and 
> group and at times, the AD users may need to work on the application, 
> view/edit files owned by the application user/group, run programs etc. 
> Therefore we need to create some sort of mapping between the AD users and the 
> local group.
> 
> After coming through this mailing list, I realized that the recommendation is 
> to add the remote AD users into the local group by way of modifying 
> /etc/group file. What I am wondering is that, is this the only way to solve 
> the problem or is there any other way (presumably better way) to handle this? 
> 
> I am using Puppet already. Therefore I think I may use the augeas provider to 
> edit /etc/group file to add the users. I also need to devise a way so that 
> users can be deleted from /etc/group easily in an automated fashion. Has 
> anyone got any tips under their sleeve that can be used to roll out this 
> feature in a lot of servers? 

If you can ensure that the remote group and the local group will always
have the same name and GID, then perhaps you could use:
https://sourceware.org/glibc/wiki/Proposals/GroupMerging
___
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://getfedora.org/code-of-conduct.html
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: Problems with subdomains_provider & group membership

[Jakub Hrozek]

On Tue, Apr 23, 2019 at 12:03:20PM +, Ondrej Valousek wrote:
> Hi List,
> I just noticed that sssd is unable to detect any groups user belongs to after 
> I set
> Subdomains_provider = none
> In my sssd.conf
> 
> Using AD provider, using token groups, not using fully qualified names.
> Is this an expected behavior?
> Note I switched subdomain_provider off as otherwise sssd keeps poking around 
> and requesting domain controllers which are not available.

btw this was solved by using ad_enabled_domains=joined.domain
___
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://getfedora.org/code-of-conduct.html
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: hostname resolution expired? (version 1.13.4-34.23.1.x86_64)

[Jakub Hrozek]

On Wed, Apr 17, 2019 at 06:21:18PM +, Beale (US), Gareth wrote:
> We are seeing the following in our sssd_default.log which appears to coincide 
> with some authentication failures. What would cause the hostname resolution 
> to expire? Can we change the length of whatever timeout might be causing this?

The resolver internally caches the host name resolution for the duration
of the TTL as provided by DNS

however, I'm not sure this is the issue, did the bind that failed with
"Can't contact LDAP server" tried to also contact the server X?

> 
> Sorry I have to obfuscate the hostnames per company policy. The host 
> "X.boeing.com" is in the sssd.conf file under the [domain/default] 
> section as:
> 
> ldap_uri = ldaps://X.boeing.com
> 
> 
> (Wed Apr 17 06:30:20 2019) [sssd[be[default]]] [be_get_account_info] 
> (0x0200): Got request for [0x1002][FAST BE_REQ_GROUP][1][idnumber=5928]
> (Wed Apr 17 06:30:20 2019) [sssd[be[default]]] [acctinfo_callback] (0x0100): 
> Request processed. Returned 0,0,Success
> (Wed Apr 17 06:31:22 2019) [sssd[be[default]]] [sdap_process_result] 
> (0x0040): ldap_result error: [Can't contact LDAP server]
> (Wed Apr 17 06:35:56 2019) [sssd[be[default]]] [be_get_account_info] 
> (0x0200): Got request for [0x3][BE_REQ_INITGROUPS][1][name=nss8297]
> (Wed Apr 17 06:35:56 2019) [sssd[be[default]]] [fo_resolve_service_send] 
> (0x0100): Trying to resolve service 'LDAP'
> (Wed Apr 17 06:35:56 2019) [sssd[be[default]]] [get_server_status] (0x0100): 
> Hostname resolution expired, resetting the server status of 'X.boeing.com'
> (Wed Apr 17 06:35:56 2019) [sssd[be[default]]] [set_server_common_status] 
> (0x0100): Marking server 'X.boeing.com' as 'name not resolved'
> (Wed Apr 17 06:35:56 2019) [sssd[be[default]]] 
> [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 
> 'X.boeing.com' in files
> (Wed Apr 17 06:35:56 2019) [sssd[be[default]]] [set_server_common_status] 
> (0x0100): Marking server 'X.boeing.com' as 'resolving name'
> (Wed Apr 17 06:35:56 2019) [sssd[be[default]]] 
> [resolv_gethostbyname_files_send] (0x0100): Trying to resolve  record of 
> 'X.boeing.com' in files
> (Wed Apr 17 06:35:56 2019) [sssd[be[default]]] [resolv_gethostbyname_next] 
> (0x0200): No more address families to retry
> (Wed Apr 17 06:35:56 2019) [sssd[be[default]]] 
> [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 
> 'X.boeing.com' in DNS
> (Wed Apr 17 06:35:56 2019) [sssd[be[default]]] [set_server_common_status] 
> (0x0100): Marking server 'X.boeing.com' as 'name resolved'
> (Wed Apr 17 06:35:56 2019) [sssd[be[default]]] [be_resolve_server_process] 
> (0x0200): Found address for server X.boeing.com: [10.234.125.55] TTL 13
> (Wed Apr 17 06:35:56 2019) [sssd[be[default]]] 
> [sdap_get_server_opts_from_rootdse] (0x0200): No known USN scheme is 
> supported by this server!
> (Wed Apr 17 06:35:56 2019) [sssd[be[default]]] [sdap_cli_auth_step] (0x0100): 
> expire timeout is 900
> (Wed Apr 17 06:35:56 2019) [sssd[be[default]]] [simple_bind_send] (0x0100): 
> Executing simple bind as: 
> cn=Y.boeing.com.*,nisMapName=netGroup.byhost,ou=enterprise,ou=unix,ou=accounts,o=boeing,c=us
> (Wed Apr 17 06:35:56 2019) [sssd[be[default]]] [fo_set_port_status] (0x0100): 
> Marking port 636 of server 'X.boeing.com' as 'working'
> (Wed Apr 17 06:35:56 2019) [sssd[be[default]]] [set_server_common_status] 
> (0x0100): Marking server 'X.boeing.com' as 'working'
> 
> 
> Gareth Beale (bemsid: 45600)
> Enterprise High Performance Computing Service
> Application Infrastructure Services
> Global Information Technology Infrastrucure Services
> Need help? http://iticket.web.boeing.com/secure/create.aspx?id=serverhpc / 
> 425-234-0911
> 

> ___
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
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://getfedora.org/code-of-conduct.html
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: Listing sudo rules

[Jakub Hrozek]

On Wed, Apr 10, 2019 at 05:46:54PM +0200, Maupertuis Philippe wrote:
> Hi,
> I need to collect various information about a server.
> Among them are the sudo rules in place.
> Is there any way to get all the sudo rules from the server itself without 
> making assumption about how the sssd is configured ?
> I know that the rules are there on the server but I don't know how to find 
> them.

https://docs.pagure.org/SSSD.sssd/users/sudo_troubleshooting.html has
some pointers.

I think there were some requests to extend sssctl to show the cached
rules, but these are not implemented yet.
___
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://getfedora.org/code-of-conduct.html
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: Fedora 29 SSSD changes/SSSD Cache Path Alternative

[Jakub Hrozek]

On Mon, Mar 25, 2019 at 11:09:44AM +0100, Lukas Slebodnik wrote:
> On (24/03/19 19:10), Gregory Carter wrote:
> >I have a diskless workstation, which I noticed recently with some updates
> >has stopped working with respect to sssd.  Here is the config which no
> >longer works:
> >
> >[domain/default]
> >id_provider = ldap
> >autofs_provider = ldap
> >auth_provider = ldap
> >chpass_provider = ldap
> >ldap_uri = ldap://named.domain.com/
> >ldap_search_base = dc=domain,dc=com
> >ldap_id_use_start_tls = True
> >ldap_tls_cacertdir = /etc/openldap/certs
> >cache_credentials = True
> >ldap_autofs_map_object_class   = automountMap
> >ldap_autofs_map_name   = ou
> >ldap_autofs_entry_object_class = automount
> >ldap_autofs_entry_key  = cn
> >ldap_autofs_entry_value= automountInformation
> >debug_level = 9
> >
> >[sssd]
> >services = nss, pam, autofs
> >domains = default
> >debug_level = 9
> >
> >[nss]
> >homedir_substring = /home
> >debug_level = 9
> >
> >[pam]
> >debug_level = 9
> >
> >[sudo]
> >debug_level = 9
> >
> >[autofs]
> >debug_level = 9
> >
> >[ssh]
> >debug_level = 9
> >
> >[pac]
> >debug_level = 9
> >
> >[ifp]
> >debug_level = 9
> >
> >[secrets]
> >debug_level = 9
> >
> >[session_recording]
> >debug_level = 9
> >
> >What I found, is that the /var/lib/sss directory is not working correctly
> >anymore with NFS root mount.
> >
> 
> Are you sure that it worked on fedora < 29 ?
> 
> NFS was never recommended for /var/lib/sss/db.

Yes, IIRC the database that ldb cache uses (tdb) was not working
properly on NFS. There were some locking issues, but I long since forgot
the details.

> 
> >Lots of timeout and error messages which, after looking at with various
> >debug levels, really didn't offer any clue to exactly why the various
> >components would time out.
> >
> >However, I did notice  the only workstation which had a issue with the
> >update was the diskless workstation, so I mounted the /var/lib/sss
> >directory on /tmp (Ram disk) which fixed the issue.
> >
> tmpfs is better for diskless workstation than NFS.
> 
> >I searched for a option to change the sssd /var/lib/sss path and did not
> >find one.
> >
> >Is there a way to change that in the /etc/sssd/sssd.conf?
> 
> No, /var/lib/sss is hardcoded.
> 
> LS
> ___
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Announcing SSSD 1.16.4

[Jakub Hrozek]

me for case insensitive domains
 * `3870 <https://pagure.io/SSSD/sssd/issue/3870>`_ - nss: memory leak in 
netgroups
 * `3451 <https://pagure.io/SSSD/sssd/issue/3451>`_ - When sssd is configured 
with id_provider proxy and auth_provider ldap, login fails if the LDAP server 
is not allowing anonymous binds.
 * `3875 <https://pagure.io/SSSD/sssd/issue/3875>`_ - CURLE_SSL_CACERT is 
deprecated in recent curl versions
 * `3902 <https://pagure.io/SSSD/sssd/issue/3902>`_ - SSSD must be 
cleared/restarted periodically in order to retrieve AD users through IPA Trust
 * `3901 <https://pagure.io/SSSD/sssd/issue/3901>`_ - sssd returns '/' for 
emtpy home directories
 * `3919 <https://pagure.io/SSSD/sssd/issue/3919>`_ - sss_cache prints spurious 
error messages when invoked from shadow-utils on package install
 * `3845 <https://pagure.io/SSSD/sssd/issue/3845>`_ - The config file validator 
says that certmap options are not allowed
 * `3937 <https://pagure.io/SSSD/sssd/issue/3937>`_ - If p11_child spawned from 
sssd_ssh times out, sssd_ssh fails completely
 * `3961 <https://pagure.io/SSSD/sssd/issue/3961>`_ - sssd config-check reports 
an error for a valid configuration option
 * `3701 <https://pagure.io/SSSD/sssd/issue/3701>`_ - [RFE] Allow changing 
default behavior of SSSD from an allow-any default to a deny-any default when 
it can't find any GPOs to apply to a user login.
 * `2474 <https://pagure.io/SSSD/sssd/issue/2474>`_ - AD: do not override 
existing home-dir or shell if they are not available in the global catalog
 * `3958 <https://pagure.io/SSSD/sssd/issue/3958>`_ - sssd_krb5_locator_plugin 
introduces delay in cifs.upcall krb5 calls
 * `3890 <https://pagure.io/SSSD/sssd/issue/3890>`_ - SSSD changes the memory 
cache file ownership away from the SSSD user when running as root
 * `3942 <https://pagure.io/SSSD/sssd/issue/3942>`_ - RemovedInPytest4Warning: 
Fixture "passwd_ops_setup" called directly
 * `3276 <https://pagure.io/SSSD/sssd/issue/3276>`_ - Revert workaround in CI 
for bug in python-{request,urllib3}
 * `3978 <https://pagure.io/SSSD/sssd/issue/3978>`_ - UPN negative cache does 
not use values from 'filter_users' config option
 * `3983 <https://pagure.io/SSSD/sssd/issue/3983>`_ - filter_users option is 
not applied to sub-domains if SSSD starts offline
 * `3947 <https://pagure.io/SSSD/sssd/issue/3947>`_ - SSSD netgroups do not 
honor entry_cache_nowait_percentage
 * `3984 <https://pagure.io/SSSD/sssd/issue/3984>`_ - IPA: Deleted user from 
trusted domain is not removed properly from the cache on IPA clients
 * `3976 <https://pagure.io/SSSD/sssd/issue/3976>`_ - crash in 
dp_failover_active_server
 * `3957 <https://pagure.io/SSSD/sssd/issue/3957>`_ - sudo: runAsUser/Group 
does not work with domain_resolution_order 
 * `1314 <https://pagure.io/SSSD/sssd/issue/1314>`_ - RFE Request for allowing 
password changes using SSSD in DS which dont follow OID's from RFC 3062
 * `3822 <https://pagure.io/SSSD/sssd/issue/3822>`_ - Enable generating user 
private groups only for users with no primary GID
 * `3963 <https://pagure.io/SSSD/sssd/issue/3963>`_ - Responders: processing of 
`filter_users`/`filter_groups` should avoid calling blocking NSS API

Packaging Changes
-
 * Several files in the reference specfile changed permissions to avoid
   issues with verifying the file integrity with ``rpm -V`` in case
   SSSD runs as a different user than the default user it is configured
   with (#3890)

Documentation Changes
-
 * The AD provider default value of ``fallback_homedir`` was changed
   to ``fallback_homedir = /home/%d/%u`` to provide home directories for
   users without the ``homeDirectory`` attribute.
 * A new option ``ad_gpo_implicit_deny``, defaulting to False (#3701)
 * A new option ``ldap_pwmodify_mode`` (#1314)
 * A new option ``pam_p11_allowed_services`` (#2926)
 * The ``auto_private_groups`` accepts a new option value ``hybrid`` (#3822)
 * Improved documentation of the Kerberos locator plugin

Detailed Changelog
--
* Alexey Tikhonov (5): 

  * Fix error in hostname retrieval 
  * lib/cifs_idmap_sss: fixed unaligned mem access 
  * ci/sssd.supp: fixed c-ares-suppress-leak-from-init 
  * negcache: avoid "is_*_local" calls in some cases 
  * Monitor: changed provider startup timeout 

* Fabiano Fidêncio (1): 

  * man/sss_ssh_knownhostsproxy: fix typo pubkeys -> pubkey 

* Jakub Hrozek (54): 

  * Updating the version to track 1.16.4 development 
  * src/tests/python-test.py is GPLv3+ 
  * src/tests/intg/util.py is licensed under GPLv3+ 
  * src/tests/intg/test_ts_cache.py is licensed under GPLv3+ 
  * src/tests/intg/test_sudo.py is licensed under GPLv3+ 
  * src/tests/intg/test_sssctl.py is licensed under GPLv3+ 
  * src/tests/intg/

[SSSD-users] Re: Announcing SSSD 2.1

[Jakub Hrozek]

On Thu, Feb 28, 2019 at 09:56:46AM +0100, Jakub Hrozek wrote:
>   == SSSD 2.1 ===
> 
> The SSSD team is proud to announce the release of version 2.1 of
> the System Security Services Daemon.
> 
> As always, the source is available from https://fedorahosted.org/sssd

Sorry about the broken link, I copied the release announcement from a
very old template. The releases are available at:
http://releases.pagure.org/SSSD/sssd/
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Announcing SSSD 2.1

[Jakub Hrozek]

 F-27 after installing sssd-kcm
 * `3567 <https://pagure.io/SSSD/sssd/issue/3567>`_ - SYSDB: Lowercased email 
is stored as nameAlias
 * `3500 <https://pagure.io/SSSD/sssd/issue/3500>`_ - Make sure sssd is a 
replacement for pam_pkcs11 also for local account authentication
 * `3489 <https://pagure.io/SSSD/sssd/issue/3489>`_ - p11_child should work wit 
openssl1.0+
 * `3451 <https://pagure.io/SSSD/sssd/issue/3451>`_ - When sssd is configured 
with id_provider proxy and auth_provider ldap, login fails if the LDAP server 
is not allowing anonymous binds.
 * `3439 <https://pagure.io/SSSD/sssd/issue/3439>`_ - Snippets are not used 
when sssd.conf does not exist
 * `3413 <https://pagure.io/SSSD/sssd/issue/3413>`_ - a bug in libkrb5 causes 
kdestroy -A to not work with more than 2 principals with KCM
 * `3334 <https://pagure.io/SSSD/sssd/issue/3334>`_ - sssctl config-check does 
not check any special characters in domain name of domain section
 * ` <https://pagure.io/SSSD/sssd/issue/>`_ - usermod -a -G bar foo 
fails due to some file providers races
 * `3276 <https://pagure.io/SSSD/sssd/issue/3276>`_ - Revert workaround in CI 
for bug in python-{request,urllib3}
 * `3263 <https://pagure.io/SSSD/sssd/issue/3263>`_ - consider adding sudo-i to 
the list of pam_response_filter services by default
 * `2817 <https://pagure.io/SSSD/sssd/issue/2817>`_ - dynamic dns - remove 
detection of 'realm' keyword support
 * `2474 <https://pagure.io/SSSD/sssd/issue/2474>`_ - AD: do not override 
existing home-dir or shell if they are not available in the global catalog
 * `1944 <https://pagure.io/SSSD/sssd/issue/1944>`_ - convert dyndns timer to 
be_ptask

Detailed Changelog
--
* Adam Williamson (1): 

  * sbus: use 120 second default timeout 

* Alexey Tikhonov (16): 

  * Fix error in hostname retrieval 
  * util/tev_curl: Fix double free error in schedule_fd_processing() 
  * CONFIG: validator rules & test 
  * sss_client/common.c: fix Coverity issue 
  * sss_client/common.c: fix off-by-one error in sizes check 
  * sss_client/common.c: comment amended 
  * sss_client/nss_services.c: indentation fixed 
  * sss_client/nss_services.c: fixed incorrect mutex usage 
  * sss_client: global unexported symbols made static 
  * providers/ldap: abort unsecure authentication requests 
  * providers/ldap: fixed check of ldap_get_option return value 
  * providers/ldap: init sasl_ssf in specific case 
  * sbus/interface: fixed interface copy helpers 
  * lib/cifs_idmap_sss: fixed unaligned mem access 
  * Util: fixed mistype in error string representation 
  * TESTS: fixed bug in guests startup function 

* George McCollister (1): 

  * build: remove hardcoded samba include path 

* Jakub Hrozek (38): 

  * Updating the version to track 2.1 development 
  * KCM: Don't error out if creating a new ID as the first step 
  * SELINUX: Always add SELinux user to the semanage database if it doesn't 
exist 
  * pep8: Ignore W504 and W605 to silence warnings on Debian 
  * TESTS: Add a test for whitespace trimming in netgroup entries 
  * TESTS: Add two basic multihost tests for the files provider 
  * FILES: The files provider should not enumerate 
  * p11: Fix two instances of -Wmaybe-uninitialized in p11_child_openssl.c 
  * UTIL: Suppress Coverity warning 
  * PYSSS: Re-add the pysss.getgrouplist() interface 
  * IFP: Use subreq, not req when calling RefreshRules_recv 
  * CI: Make the c-ares suppression file more relaxed to prevent failures 
on Debian 
  * INI: Return errno, not -1 on failure from sss_ini_get_stat 
  * MONITOR: Don't check for pidfile if SSSD is already running 
  * SSSD: Allow refreshing only certain section with --genconf 
  * SYSTEMD: Re-read KCM configuration on systemctl restart kcm 
  * TEST: Add a multihost test for sssd --genconf 
  * TESTS: Add a multihost test for changing sssd-kcm debug level by just 
restarting the KCM service 
  * RESPONDER: Log failures from bind() and listen() 
  * LDAP: minor refactoring in auth_send() to conform to our coding style 
  * LDAP: Only authenticate the auth connection if we need to look up user 
information 
  * PROXY: Copy the response to the caller 
  * NSS: Avoid changing the memory cache ownership away from the sssd user 
  * KCM: Deleting a non-existent ccache should not yield an error 
  * TESTS: Add a test for deleting a non-existent ccache with KCM 
  * MAN: Explicitly state that not all generic domain options are supported 
for the files provider 
  * AD/IPA: Reset subdomain service name, not domain name 
  * IPA: Add explicit return after tevent_req_error 
  * MULTIHOST: Do not use the deprecated namespace 
  * KCM: Return a valid tevent error code if a request cannot be create

[SSSD-users] Re: How to keep the password in sync with AD?

[Jakub Hrozek]

On Thu, Feb 28, 2019 at 12:29:30AM -, Ian Puleston wrote:
> "SunnyvaleSite" is correct, and adding that as ad_site is what fixed (or 
> worked-around) the problem.
> 
> > what do you mean by "did not try to use that when it could not look it up 
> > while online" ?
> 
> When I was online (without ad_site in sssd.conf) the log showed the "Could 
> not autodiscover AD site" messages above, and there, or just after it, the 
> attempt ended.
> 
> When I was offline then it showed the "Looking up domain controllers in 
> domain sv.us.sonicwall.com and site "SunnyvaleSite" (with that DNS lookup 
> failing since I was offline) before it logged me in with the cached info.
> 
> So somehow it knew the site name without being able to look it up online.

IIRC they way the code works is that it always goes through the site
discovery branch (because the site discovery request also discovers the
forest name) and then just throws away the site override if there's an
ad_site explicitly defined.
___
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://getfedora.org/code-of-conduct.html
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: ldap_id_mapping=True login linux the user UID auto change

[Jakub Hrozek]

On Wed, Feb 27, 2019 at 01:13:03AM -, CharlesLee  wrote:
> Hi Jakub,
> Thanks for your reply.
> 
> I was turn off ldap_id_mapping and use POSIX IDs, then the user can not use 
> password of AD.
> The user can not verify the login linux use AD's password.

But it would be nice to see some debug logs to know what exactly is
happening..

> So I tune the range sizes for control the uid in 4 digits.
> 
> ___
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
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://getfedora.org/code-of-conduct.html
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: How to keep the password in sync with AD?

[Jakub Hrozek]

On Wed, Feb 27, 2019 at 12:59:27AM -, Ian Puleston wrote:
> Hi,
> 
> Thanks for the help. I now seem to have the problem sorted out and things are 
> now working OK after a configuration change:
> 
> I did have to rejoin the domain first, and that did not go very smoothly. 
> Having successfully used "realm leave", trying to do "realm join" (with the 
> help of an IT guy for the administrator password) would not work, failing to 
> accept my password. Then the IT guy had the idea to rename my laptop so that 
> it would start fully afresh, creating a new "computer" entry in AD (actually 
> the IT guy created that manually, I think), and rather surprisingly to me, 
> this worked.
> 
> However, I then found that I was back to an earlier state where I could not 
> log in with my valid domain password while connected to the network, but 
> could log in with the (new) cached credentials if I disconnected from it. I 
> was earlier having this issue before getting into the state that I reported 
> above, and I now think that it is probably what led to that.
> 
> So I did some debugging and found this in the SSSD log after a failed login:
> 
> (Tue Feb 26 16:20:37 2019) [sssd[be[sv.us.sonicwall.com]]] 
> [ad_gpo_site_name_retrieval_done] (0x0400): Could not autodiscover AD site. 
> This is not fatal if ad_site option was set.
> (Tue Feb 26 16:20:37 2019) [sssd[be[sv.us.sonicwall.com]]] 
> [ad_gpo_site_name_retrieval_done] (0x0040): Could not autodiscover AD site 
> value using DNS and ad_site option was not set in configuration. GPO will not 
> work. To work around this issue you can use ad_site option in SSSD 
> configuration.
> (Tue Feb 26 16:20:37 2019) [sssd[be[sv.us.sonicwall.com]]] 
> [ad_gpo_process_som_done] (0x0040): Unable to get som list: [2](No such file 
> or directory)
> (Tue Feb 26 16:20:37 2019) [sssd[be[sv.us.sonicwall.com]]] 
> [ad_gpo_access_done] (0x0040): GPO-based access control failed.
> 
> So I added the ad_site name into my sssd.conf, and with that all now seems to 
> be working fine.
> 
> But what is rather strange about this is that after that authentication 
> failure while online, I would pull out the Ethernet cable and log in with 
> cached credentials, and the SSSD log for the latter includes this:
> 
> (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] 
> [ad_srv_plugin_send] (0x0400): About to find domain controllers
> (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] 
> [ad_get_dc_servers_send] (0x0400): Looking up domain controllers in domain 
> sv.us.sonicwall.com and site SunnyvaleSite
> (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] 
> [resolv_discover_srv_next_domain] (0x0400): SRV resolution of service 'ldap'. 
> Will use DNS discovery domain 'SunnyvaleSite._sites.sv.us.sonicwall.com'
> (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] 
> [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of 
> '_ldap._tcp.SunnyvaleSite._sites.sv.us.sonicwall.com'
> (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] 
> [request_watch_destructor] (0x0400): Deleting request watch
> (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] 
> [resolv_discover_srv_done] (0x0040): SRV query failed [11]: Could not contact 
> DNS servers
> (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] 
> [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'not 
> working'
> (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] [resolve_srv_done] 
> (0x0040): Unable to resolve SRV [1432158237]: SRV lookup error
> (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] 
> [set_srv_data_status] (0x0100): Marking SRV lookup of service 'AD' as 'not 
> resolved'
> 
> So it has remembered the site name, yet did not try to use that when it could 
> not look it up while online?

So authentication always (almost) tries to connect to the back end. This
looks to me like the auth request tries to connect and fails. I also see
"SunnyvaleSite" being used. Is it not the correct one?

Or maybe I don't understand exactly what do you mean by "did not try to
use that when it could not look it up while online" ?
___
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://getfedora.org/code-of-conduct.html
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: No netgroup_provider?

[Jakub Hrozek]

On Mon, Feb 18, 2019 at 06:34:54PM +0100, Lukas Slebodnik wrote:
> >Also, any particular reason there’s not a netgroup_provider?
> >
> 
> Because netgroups are part of id_provider
> The same as users, groups and service. (There is neither user_provider nor
> group_provider ...)

btw the reasoning behind this is basically 'if it has an nsswitch map
provided by libc, it should be part of the ID provider'
___
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://getfedora.org/code-of-conduct.html
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: ldap_id_mapping=True login linux the user UID auto change

[Jakub Hrozek]

On Mon, Feb 18, 2019 at 03:27:57PM -, CharlesLee  wrote:
> Hi Jakub,
> 
> Because I want to control the uid in 4 digits.

I would suggest that the ID mapping is not the right tool, then and
using POSIX IDs might be better.
___
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://getfedora.org/code-of-conduct.html
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: ldap_id_mapping=False then AD user's password not availabe

[Jakub Hrozek]

On Mon, Feb 18, 2019 at 03:21:55PM -, CharlesLee  wrote:
> Hi Jakub，
> 
> Yes, I did rm -rf /var/lib/sss/db/* after turn off ldap_id_mapping.
> In the linux AD's user can have  uidNumber, but the AD user's password was 
> invalid in linux.

Then please follow the debugging steps:
https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html
___
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://getfedora.org/code-of-conduct.html
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: ldap_id_mapping=True login linux the user UID auto change

[Jakub Hrozek]

On Mon, Feb 18, 2019 at 03:36:48AM -, CharlesLee  wrote:
> Hi, everyone
> 
> I have a problem with sssd 1.16.0 use in CentOS7 with AD(windows server 
> 2008R2).
> 
> I'm use realm join the AD，and sssd config is next:
> [domain/default]
> autofs_provider = ldap
> cache_credentials = True
> krb5_realm = ARD.INC
> ldap_search_base = dc=BEIJ,dc=inc
> id_provider = ldap
> auth_provider = ldap
> chpass_provider = ldap
> ldap_uri = ldap://192.168.201.207/
> ldap_id_use_start_tls = False
> ldap_tls_cacertdir = /etc/openldap/cacerts
> 
> [sssd]
> domains = default, ARD.inc
> config_file_version = 2
> services = nss, pam
> [pam]
> 
> [autofs]
> 
> [domain/ARD.inc]
> ad_domain = ARD.inc
> krb5_realm = ARD.INC
> realmd_tags = manages-system joined-with-samba 
> cache_credentials = True
> id_provider = ad
> krb5_store_password_if_offline = True
> default_shell = /bin/bash
> ldap_sasl_authid = YW-CLUSTER-LOGI$
> ldap_id_mapping = true
> use_fully_qualified_names = False
> fallback_homedir = /home/%u
> access_provider = ad
> ldap_idmap_range_min = 5000
> ldap_idmap_range_max = 7000
> ldap_idmap_range_size = 10
> 
> At the beginning it's running very good.
> But the recent we discovery some user's UID have changed , the UID auto +10.
> For example, the UID initial is 5333 then user UID auto change to 5343.
> 
> Why?

I assume the non-defaults range sizes have something to do with it? Why
did you tune the range sizes, isn't the default good enough?
___
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://getfedora.org/code-of-conduct.html
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: Any way to disallow unauthorized users in the pam "authentication" phase instead of "account" phase?

[Jakub Hrozek]

On Fri, Feb 15, 2019 at 09:02:44PM -0600, Spike White wrote:
> All,
> 
> This is not a big deal -- just curious.
> 
> We have a commercial Linux AD integration product.  In it, the incoming
> user's authorization to log in is validated during the PAM "authentication"
> phase.  So if it's a legal AD user and good password, but that user is not
> authorized in -- you're returned to the "login name: / password:" prompt.
> 
> In sssd, it appears that validating if you're a legally-authorized user or
> in a legally-authorized group occurs in the PAM "account" phase.  It's done
> by the "simple" access_provider.
> 
> Consider again a legal AD user and good password, but again -- that user is
> not authorized in.
> 
> Now that user name is accepted, that password is accepted, but then the
> server closes your putty session.  You're not returned to a "login name: /
> password:" prompt.
> 
> Like I say -- not a big deal.  Unauthorized users are intercepted and
> disallowed, just in different ways.  Just curious if there's a way to make
> sssd fail in the former manner, instead of the latter.

No, I can't think of any, sorry. All the access checks are invoked from
pam_sss's account module.
___
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://getfedora.org/code-of-conduct.html
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: ldap_id_mapping=False then AD user's password not availabe

[Jakub Hrozek]

On Fri, Feb 15, 2019 at 09:47:46AM -, CharlesLee  wrote:
> Hi sumit,
> 
> Thanks for your reply.
> 
> I'm using windows server 2008R2 AD.
> I use "ldap_id_mapping=False" because I want the AD's user in linux UID is 
> gidNumber, if I use "ldap_id_mapping=True" the user's uid in linux will can 
> not control.
> 
> I want to the AD user in linux can use gidNumber and AD user login linux use 
> AD password.
> So, How should I do ?

Do you already have the IDs created and stored in AD?

One thing you might need to do after switching the ID mapping on or off
is to clear the sssd cache. With newer versions:
sssctl cache-remove
or with older versions:
rm -f /var/lib/sss/db/*
systemctl restart sssd
___
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://getfedora.org/code-of-conduct.html
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: password not complex enough error for AD users

[Jakub Hrozek]

On Fri, Feb 08, 2019 at 02:39:18PM -, robert wild wrote:
> do i need to enable logging for this?

yes.
___
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://getfedora.org/code-of-conduct.html
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: password not complex enough error for AD users

[Jakub Hrozek]

On Thu, Feb 07, 2019 at 11:29:48PM -, robert wild wrote:
> hi all,
> 
> i have got sssd on a centos 7 vm and i have got it working
> 
> https://www.linuxtechi.com/integrate-rhel7-centos7-windows-active-directory/
> 
> as when i do
> 
> id AD_user
> 
> it comes up with the uid, gid and all the group members that user belongs to 
> also they can login on the logon page using there AD accounts
> 
> but when they open up a terminal window i want it so they can change there 
> passwords
> 
> i have added to my "/etc/sssd/sssd.conf" file these two lines from this link
> 
> https://linux.die.net/man/5/sssd.conf
> 
> pwd_expiration_warning = 7
> 
> chpass_provider = ad
> 
> but they get this error when they try to change there passwords
> 
> [robert.wild@lon-p-xrdp01 ~]$ passwd
> Changing password for user robert.wild.
> Current Password:
> New password:
> Retype new password:
> Password change failed. Server message: Please make sure the password meets 
> the complexity constraints.
> passwd: Authentication token manipulation error
> [robert.wild@lon-p-xrdp01 ~]$
> 
> but i know i do meet the password requirements as i have added 13 characters 
> including upper/lower/numbers/special characters
> 
> has anyone got sssd to change user passwords
> 
> thanks,
> 
> rob

krb5_child.log might have some more useful information..
___
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://getfedora.org/code-of-conduct.html
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: How to keep the password in sync with AD?

[Jakub Hrozek]

On Tue, Feb 05, 2019 at 10:13:41PM -, Ian Puleston wrote:
> Thanks for the suggestion Sumit. Your kinit command gave this output:
> 
> kinit: Pre-authentication failed: Permission denied while getting initial 
> credentials
> 
> I wasn't sure if I should run that direct from my domain user account or with 
> su privilege, so tried the same with sudo and that gave:
> 
> kinit: Keytab contains no suitable keys for ian-lap...@sv.us.sonicwall.com 
> while getting initial credentials

Are you sure you quoted the trailing '$' in the principal name? e.g. you
should call this:
kinit -k 'IAN-LAPTOP$@SV.US.SONICWALL.COM'

> 
> ldap_child.log contains just this (repeatedly):
> 
> (Tue Feb  5 14:00:15 2019) [[sssd[ldap_child[13905 [main] (0x0400): 
> ldap_child started.
> (Tue Feb  5 14:00:15 2019) [[sssd[ldap_child[13905 [unpack_buffer] 
> (0x0200): Will run as [0][0].
> (Tue Feb  5 14:00:15 2019) [[sssd[ldap_child[13905 [become_user] 
> (0x0200): Trying to become user [0][0].
> (Tue Feb  5 14:00:15 2019) [[sssd[ldap_child[13905 [become_user] 
> (0x0200): Already user [0].
> (Tue Feb  5 14:00:15 2019) [[sssd[ldap_child[13905 
> [ldap_child_get_tgt_sync] (0x0100): Principal name is: 
> [IAN-LAPTOP$@SV.US.SONICWALL.COM]
> (Tue Feb  5 14:00:15 2019) [[sssd[ldap_child[13905 
> [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab]
> (Tue Feb  5 14:00:15 2019) [[sssd[ldap_child[13904 
> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: 
> Preauthentication failed
> (Tue Feb  5 14:00:15 2019) [[sssd[ldap_child[13904 [main] (0x0020): 
> ldap_child_get_tgt_sync failed.
> (Tue Feb  5 14:00:15 2019) [[sssd[ldap_child[13904 [prepare_response] 
> (0x0400): Building response for result [-1765328360]
> (Tue Feb  5 14:00:15 2019) [[sssd[ldap_child[13904 [main] (0x0400): 
> ldap_child completed successfully
> (Tue Feb  5 14:00:15 2019) [[sssd[ldap_child[13905 
> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: 
> Preauthentication failed

This means the machine credentials in the keytab cannot be used to
authenticate to the server, most probably the client has to be re-joined
or the keytab otherwise regenerated.

> (Tue Feb  5 14:00:15 2019) [[sssd[ldap_child[13905 [main] (0x0020): 
> ldap_child_get_tgt_sync failed.
> (Tue Feb  5 14:00:15 2019) [[sssd[ldap_child[13905 [prepare_response] 
> (0x0400): Building response for result [-1765328360]
> (Tue Feb  5 14:00:15 2019) [[sssd[ldap_child[13905 [main] (0x0400): 
> ldap_child completed successfully
> 
> Ian
> ___
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
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://getfedora.org/code-of-conduct.html
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: SSSD : id don't display groups name subdomain (Child trust)

[Jakub Hrozek]

On Tue, Feb 05, 2019 at 08:52:27AM +, Martial CHAVIGNY wrote:
> Hi everyone,
> 
> In dev environnement, with SSSD 1.16.2 (release 13.el7_6.5) on RHEL 7.6
> 
> SSSD is configured to request on mch.dev domain. trusted subdomain 
> sub.mch.dev exist (Win2k16)
> 
> On mch.dev, I have an user 'user1' in Universal groups 'G_TEST' and 
> 'allowed_ssh'. These groups are placed also in mch.dev domain.
> On sub.mch.dev, I have user 'user2' only. 'user2' is place in 'G_TEST' and 
> 'allowed_ssh'.
> 
> When get id user from mch.dev domain, by `id mch\user1` I get this result : 
> `uid=83701115(user1) gid=513(sssdgrp) 
> groups=513(sssdgrp),83701107(allowed_ssh),83701117(g_test)`, but `id 
> sub\user2`, in same group (universal - child trust), I get 
> `uid=69901104(user2) gid=69901104(user2) groups=69901104(user2)` without 
> group name
> 
> getent work fine : `getent group 'g_test'` result : 
> `g_test:*:83701117:user2,user1,mch`
> 
> Why I have not groupname for user2 ?

This looks like an error:
(Mon Feb  4 23:03:11 2019) [sssd[be[MCH.DEV]]] [sysdb_search_object_attr] 
(0x0400): No such entry.
(Mon Feb  4 23:03:11 2019) [sssd[be[MCH.DEV]]] [sysdb_get_real_name] (0x0040): 
Cannot find user [us...@mch.dev] in cache
(Mon Feb  4 23:03:11 2019) [sssd[be[MCH.DEV]]] [sdap_get_initgr_user] (0x0040): 
Cannot canonicalize username
(Mon Feb  4 23:03:11 2019) [sssd[be[MCH.DEV]]] [sdap_id_op_done] (0x4000): 
releasing operation connection

I don't know why is sysdb_get_real_name() looking for the entry in the
mch.dev domain and not the subdomain.

Can you remove the full_name_format option from the [sssd] section instead,
if you need to use short names, set use_fully_qualified_names=false. Since
recent versions you can set this option also for subdomains, but I would
suggest to first test with a very vanilla configuration.

btw was there a reason to unset tokengroups?

> 
> sssd.conf :
> 
> [sssd]
> domains = mch.dev
> config_file_version = 2
> services = nss, pam
> default_domain_suffix = mch.dev
> full_name_format = %1$s
> 
> [nss]
> filter_users = root
> reconnection_retries = 3
> entry_cache_nowait_percentage = 75
> 
> [pam]
> pam_pwd_expiration_warning = 21
> pam_account_expired_message = Account/password expired, please use 
> selfservice portal to change your password and logon again.
> 
> [domain/MCH.DEV]
> debug_level = 9
> id_provider = ad
> access_provider = ad
> auth_provider = ad
> ad_domain = mch.dev
> krb5_realm = MCH.DEV
> krb5_store_password_if_offline = True
> cache_credentials = True
> default_shell = /bin/bash
> ldap_id_mapping = True
> use_fully_qualified_names = True
> override_gid = 513
> fallback_homedir = /home/%u@%d
> default_shell = /bin/bash
> dyndns_update = false
> ldap_idmap_range_min = 10
> ldap_use_tokengroups = False
> 
> krb5.conf
> includedir /etc/krb5.conf.d/
> 
> includedir /var/lib/sss/pubconf/krb5.include.d/
> [logging]
> default = FILE:/var/log/krb5libs.log
> kdc = FILE:/var/log/krb5kdc.log
> admin_server = FILE:/var/log/kadmind.log
> 
> [libdefaults]
> dns_lookup_realm = false
> ticket_lifetime = 24h
> renew_lifetime = 7d
> forwardable = true
> rdns = false
> default_ccache_name = KEYRING:persistent:%{uid}
> default_realm = MCH.DEV
> 
> [realms]
> MCH.DEV = {
> }
> 
> [domain_realm]
> mch.dev = MCH.DEV
> .mch.dev = MCH.DEV
> 
> Logs available here: https://pastebin.com/Ntt62Cxt
> 
> Thanks in advance
> 
> @Jakub Hrozek jhro...@redhat.com<mailto:jhro...@redhat.com>
> With the configuration above, Inverse of your problem : I can't view and use 
> group for sub domain user, but I can login with SSH like this : 'ssh -l 
> 'sub\user2' 172.31.8.88'
___
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://getfedora.org/code-of-conduct.html
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: Best practice, experience with NIS => AD migrations?

[Jakub Hrozek]

On Mon, Feb 04, 2019 at 03:19:27PM -0600, Spike White wrote:
> Sssd practitioners,
> 
> (I hope this topic is not inappropriate to this target audience.)
> 
> My company is looking at retiring NIS, in favor of AD.  Altogether, there
> are several thousand Linux servers (& a few UNIX servers) getting their
> authentication via NIS.
> 
> There’s three components being looked up from NIS:
> 
> · Users and groups
> 
> · Automount maps
> 
> · netgroups
> 
> Additionally, there’s thousands of Linux servers getting their
> authentication via our corporate AD domain.   (Using commercial products).
> The corporate AD domain has the rfc2307bis schema extension.  Also, it has
> child domains – so cross-domain authentication (between
> transitively-trusted subdomains) is important to us.
> 
> We have kicked the tires on sssd on RHEL7.  As long as you avoid using the
> ‘tokengroups’ optimization, it works great.  Even does all cross-domain
> authentication.  We’re able to pick up users, groups and even automount
> maps.
> 
> We believe that we can mostly replace the NIS netgroups with AD groups
> (because these NIS netgroups are not using the “server” component).
> 
> We have a wealth of AD and some NIS expertise in-house.  We have
> considerable expertise in two commercial AD integration products for
> Linux/UNIX.
> 
> What we do *NOT* have is any experience with a NIS => AD migration.

Me neither, but I'll add some minor comments about SSSD.

> 
> What problems will we encounter?
> 
> 1.   We know that some NIS UIDs and GIDs will conflict with
> already-existing AD entries.

In general SSSD does not support conflicting IDs, but..

> 
> 2.   If we change these users’ UIDs to non-conflicting UIDs, then our
> NFS NAS shares will break (as the directory trees are owned by the old UID,
> not the new UID).

..there is a utility called sss_override that might help you set up a
per-client UID and GID override if that would help.

> 
> What other problems do we need to look out for?
> 
> Here’s our initial idea of how to proceed:
> 
> 1.   We’re thinking of standing up RHEL8 with sssd first.

As far as the AD integration goes, RHEL-8 is pretty much equivalent to
RHEL-7. There are differences wrt smart cards and Kerberos ticket
handling as well as many changes under the hood which would allow us to
do more enhancements down the road in RHEL-8, but I would say that for
AD integration purposes, you can just go ahead with RHEL-7..

> 
> 2.   After period of stability:
> 
> a.   Forklift NIS accounts into AD, deconflicting UIDs and GIDs.
> 
> b.  Stand up new NAS shares with new UIDs, GIDs?
> 
> c.   retrofit RHEL7 (remove NIS, put in AD on RHEL7 clients).
> 
> 
> 
> 3.   After period of stability, do same with RHEL6 and RHEL5 – except
> with commercial products.  (version of sssd on RHEL5 and RHEL6 too old and
> flaky – particularly for cross-domain auth).

The 6.10 version /should/ be relatively stable and I'm not aware of many
issues. RHEL-5 on the other hand is EOL for most intents and purposes..

> 
> Are we totally off on the above roll-out plan?
> 
> What are best practices?
> 
> Does anyone have experience with such a NIS => AD large corporate migration?
> 
> Spike

> ___
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
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://getfedora.org/code-of-conduct.html
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: AD multiple domains - login failed for child domain

[Jakub Hrozek]

On Thu, Jan 31, 2019 at 04:27:02PM +0100, Jeremy Monnet wrote:
> Hello,
> 
> I never fixed issues I had last year
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/thread/5XUJLUVI5JZILZKDK5DRHK7PSQNIZZBD/
> but I did made a new test on a brand new ubuntu up to date, and the
> result is far better, though everything is not working.
> 
> As a reminder, I have an AD with a parent and a child domain, let's
> say example.com and child.example.com. For the new server I set up, I
> used system provided utilities
> realm join example.com -U 'u...@example.com'
> which pretty much generates
> 
> root@ubuntu:/var/log/sssd# cat /etc/sssd/sssd.conf
> [sssd]
> domains = example.com
> config_file_version = 2
> services = nss, pam
> [domain/example.com]
> ad_domain = example.com
> krb5_realm = EXAMPLE.COM
> 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 = False
> use_fully_qualified_names = False
> fallback_homedir = /home/%u@%d
> debug_level=9
> access_provider = ad
> 
> Now, everything is OK with the main domain, AFAIK, I can login, sudo
> based on groups, etc. But for the child domain, most work, I can id a
> user@child (that resolves the user and the groups associated), I can
> "su - user@child" from root, BUT I can not login with that user@child.
> Sanitized logs follow :
> 
> sssd_example.com.log
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD'
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]] [get_server_status]
> (0x1000): Status of server '' is 'working'
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]] [get_port_status]
> (0x1000): Port status of port 389 for server '' is 'working'
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to
> 6 seconds
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]] [resolve_srv_send]
> (0x0200): The status of SRV lookup is resolved
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]] [get_server_status]
> (0x1000): Status of server '' is 'working'
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [be_resolve_server_process] (0x1000): Saving the first resolved server
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [be_resolve_server_process] (0x0200): Found address for server :
> [IP] TTL 3600
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [ad_resolve_callback] (0x0100): Constructed uri 'ldap://'
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [ad_resolve_callback] (0x0100): Constructed GC uri 'ldap://'
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [unique_filename_destructor] (0x2000): Unlinking
> [/var/lib/sss/pubconf/.krb5info_dummy_ivIwhy]
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]] [unlink_dbg]
> (0x2000): File already removed:
> [/var/lib/sss/pubconf/.krb5info_dummy_ivIwhy]
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [sss_domain_get_state] (0x1000): Domain child.example.com is Active
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [child_handler_setup] (0x2000): Setting up signal handler up for pid
> [30303]
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [child_handler_setup] (0x2000): Signal handler set up for pid [30303]
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [write_pipe_handler] (0x0400): All data has been sent!
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]] [read_pipe_handler]
> (0x0400): EOF received, client finished
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]] [krb5_auth_done]
> (0x0040): The krb5_child process returned an error. Please inspect the
> krb5_child.log file or the journal for more information
> 
> 
> krb5_child.log
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393070: Sending
> TCP request to stream :88
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393071:
> Received answer (317 bytes) from stream :88
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393072:
> Terminating TCP connection to stream :88
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393073:
> Response was from master KDC
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393074:
> Decoding FAST response
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393075: TGS
> request result: -1765328377/Server not found in Kerberos database
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393076:
> Requesting tickets for 

[SSSD-users] Re: SSSD for keycloak intergration

[Jakub Hrozek]

On Tue, Jan 29, 2019 at 10:22:38PM +0530, sheetalmane4 wrote:
> Hi,
> 
> Is there an any possibility to use keycloak as a user management and SSSD
> for linux user authentication ?

It is posible to fetch user data via SSSD from whatever source SSSD can
access:
https://www.keycloak.org/docs/4.8/server_admin/index.html#_sssd
___
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://getfedora.org/code-of-conduct.html
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: Sssd and gidNumber

[Jakub Hrozek]

On Wed, Jan 16, 2019 at 05:33:41AM -, Dmitrij S. Kryzhevich wrote:
> I have setup with 3 clients and server. Server runs samba as AD and ldap + 
> kerberos. Clients use sss: 1) fedora with 2.0.0, 2) centos with 1.16.0 and 3) 
> centos with 1.16.2. All clients use 1:1 sssd.conf. I want sss to use primary 
> group id from gidNumber record in ldap and I have no issues with first and 
> second clients. But not third. I don't understand why but primary gid is set 
> equal to uid. Can't see anything relevant in logs.
> 
> Where to dig?

I would start with comparing logs for a 'working' and a 'non-working'
client. The config looks OK to me and in general the plain LDAP provider
should only ever generate the gidNumber value if
ldap_auto_private_groups is set to True

> 
> sssd.conf:
> [domain/default]
> id_provider = ldap
> ldap_uri = ldap://pdc.lkkm/
> ldap_id_use_start_tls = True
> ldap_tls_cacertdir = /etc/openldap/cacerts
> ldap_search_base = dc=pdc,dc=lkkm
> ldap_default_bind_dn = 
> ldap_default_authtok_type = password
> ldap_default_authtok = 
> ldap_user_search_base = cn=Users,dc=pdc,dc=lkkm
> ldap_user_home_directory = unixHomeDirectory
> ldap_user_object_class = person
> ldap_group_search_base = dc=PosixGroups,dc=pdc,dc=lkkm
> ldap_group_object_class = group
> 
> auth_provider = krb5
> chpass_provider = krb5
> krb5_server = pdc.lkkm
> krb5_kpasswd = pdc.lkkm
> krb5_realm = PDC.LKKM
> krb5_store_password_if_offline = False
> krb5_ccname_template = KEYRING:persistent:%{uid}
> krb5_auth_timeout = 15
> ___
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
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://getfedora.org/code-of-conduct.html
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: Understanding sssd cache

[Jakub Hrozek]

On Wed, Jan 16, 2019 at 03:50:59PM +0100, Maupertuis Philippe wrote:
> 
> 
> > -Message d'origine-----
> > De : Jakub Hrozek [mailto:jhro...@redhat.com]
> > Envoyé : mercredi 16 janvier 2019 15:24
> > À : sssd-users@lists.fedorahosted.org
> > Objet : [SSSD-users] Re: Understanding sssd cache
> >
> > On Wed, Jan 16, 2019 at 01:45:35PM +0100, Maupertuis Philippe wrote:
> > >
> > >
> > > > -Message d'origine-
> > > > De : Lukas Slebodnik [mailto:lsleb...@redhat.com]
> > > > Envoyé : mercredi 16 janvier 2019 12:47
> > > > À : End-user discussions about the System Security Services Daemon
> > > > Objet : [SSSD-users] Re: Understanding sssd cache
> > > >
> > > > On (16/01/19 09:14), Maupertuis Philippe wrote:
> > > > >Hi
> > > > >I am trying to find out how th sssd cache is being populated.
> > > > >I couldn't find much about it so I did some tests.
> > > > >It seems that with enumerate = true, the cache holds all the 
> > > > >information
> > > > needed as soon as sssd is started.
> > > > >With enumerate = false, the cache holds information about someone
> > only
> > > > after his first connection.
> > > > >Is that right ?
> > > > >I would like to be sure that user's passwords are stored in the cache 
> > > > >but
> > > > couldn't find any way to verify this
> > > > >With sssctl user-show  I can find if a user is in the cache but with no
> > details.
> > > > >With sssctl user-checks I get some information about the user but
> > nothing
> > > > about the password.
> > > > >By examining directly the cache with ldbsearch I don't find any 
> > > > >password
> > > > information either, only maybe shadowLastChange: with a number which
> > I
> > > > don't understand.
> > > > >Is there any documentation about the cache management ?
> > > > >
> > > >
> > > > Hashed password is cached only after successful authentication. It is 
> > > > not
> > > > rerieved by "getent passwd $user".
> > > >
> > > > sssd cache is internal cache and should not be used directly by user.
> > > I understand that and was looking at it only to try to understand how it
> > works.
> > >
> > > > May I know what do you want to achieve?
> > > When using regular ssh access the the ssh publickey is in the cache if
> > needed.
> > > A user who had not connected previously is able to connect even if the
> > backend is unreachable
> > > When using the console, we have to rely on the password.
> > > When something goes wrong (sshd down or network issue), there is a high
> > probability that the user would connect to the console for the first time.
> > > So if there is no guarantee the login could be successful offline we need 
> > > to
> > have a local  (shared) account to connect to the console.
> > > A shared account is a nightmare to manage and a sore point for audits, we
> > would like to remove it.
> >
> > The sss_seed tool was meant as a way to mitigate this.
> If I understand it correctly to have only nominative account in place for 
> console login, each user would have to put his own password in the cache 
> before something goes wrong.
> Obviously it won't work in a large environment.
> So we can't rely on SSSD and its cache for console login, a local user is 
> mandatory.

If you're going to orchestrate useradd for each local user, how is that
more difficult than sss_seed for each remote user?
___
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://getfedora.org/code-of-conduct.html
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: Understanding sssd cache

[Jakub Hrozek]

On Wed, Jan 16, 2019 at 01:45:35PM +0100, Maupertuis Philippe wrote:
> 
> 
> > -Message d'origine-
> > De : Lukas Slebodnik [mailto:lsleb...@redhat.com]
> > Envoyé : mercredi 16 janvier 2019 12:47
> > À : End-user discussions about the System Security Services Daemon
> > Objet : [SSSD-users] Re: Understanding sssd cache
> >
> > On (16/01/19 09:14), Maupertuis Philippe wrote:
> > >Hi
> > >I am trying to find out how th sssd cache is being populated.
> > >I couldn't find much about it so I did some tests.
> > >It seems that with enumerate = true, the cache holds all the information
> > needed as soon as sssd is started.
> > >With enumerate = false, the cache holds information about someone only
> > after his first connection.
> > >Is that right ?
> > >I would like to be sure that user's passwords are stored in the cache but
> > couldn't find any way to verify this
> > >With sssctl user-show  I can find if a user is in the cache but with no 
> > >details.
> > >With sssctl user-checks I get some information about the user but nothing
> > about the password.
> > >By examining directly the cache with ldbsearch I don't find any password
> > information either, only maybe shadowLastChange: with a number which I
> > don't understand.
> > >Is there any documentation about the cache management ?
> > >
> >
> > Hashed password is cached only after successful authentication. It is not
> > rerieved by "getent passwd $user".
> >
> > sssd cache is internal cache and should not be used directly by user.
> I understand that and was looking at it only to try to understand how it 
> works.
> 
> > May I know what do you want to achieve?
> When using regular ssh access the the ssh publickey is in the cache if needed.
> A user who had not connected previously is able to connect even if the 
> backend is unreachable
> When using the console, we have to rely on the password.
> When something goes wrong (sshd down or network issue), there is a high 
> probability that the user would connect to the console for the first time.
> So if there is no guarantee the login could be successful offline we need to 
> have a local  (shared) account to connect to the console.
> A shared account is a nightmare to manage and a sore point for audits, we 
> would like to remove it.

The sss_seed tool was meant as a way to mitigate this.
___
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://getfedora.org/code-of-conduct.html
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: Sudo in a ldap

[Jakub Hrozek]

On Mon, Jan 14, 2019 at 09:06:31AM +0100, Maupertuis Philippe wrote:
> Hi,
> I am new on this mailing list so please forgive me if my question has already 
> been answered.
> I did read the archive to try find something.
> 
> My d.conf retrieve the information from a 389ds ldap including sudo rules.
> Everything is working fine except for one point regarding sudo.
> For a given user only one entry  is fetched from the ldap.
> Is it working as intended ?
> What I would like to achieve is basically something as simple as :
> User => root  :some commands
> User  => mysql : ALL
> This is easily done with a local sudoers, but I failed to have it working 
> with sssd and the ldap.

This is a good starting point regarding sudo troubleshooting:
https://docs.pagure.org/SSSD.sssd/users/sudo_troubleshooting.html

Posting the rules LDIF might be a good idea as well.
___
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://getfedora.org/code-of-conduct.html
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: sssd: AD service discovery and invalidating cache

[Jakub Hrozek]

On Mon, Jan 07, 2019 at 06:01:08PM +, R Davies wrote:
> On Fri, 4 Jan 2019 at 10:19, Jakub Hrozek  wrote:
> 
> > Would the stickiness also persist across SRV priority levels? What I
> > mean is that if server1 had originally the highest priority (the lowest
> > priority value in the SRV record), but then the SRV record is expired
> > and the server is suddendly in a lower priority tier, IMO then the server
> > should be 'forgotten' and a new one chosen..
> >
> 
> You're right to highlight this.  Different admins may have different
> requirements,  perhaps the configuration option "ad_sticky" could control
> behaviour:
> 
> always - Always sticky, prefer the originally discovered server, unless the
> sticky server has been removed from the service record
> priority - Mostly sticky, prefer the originally discovered server, unless
> its priority in the service record has changed
> never - No stickiness (default, and current behaviour), i.e. always
> potentially change ldap server on expiry of the ldap connection.

As long as the default behaviour stays the same, I'm fine with just
implementing never and always or never and priority. I think it's just
important not to prevent extending the code further.

> 
> In terms of implementation, would this be confined to the AD provider or
> would IPA also benefit with this?  If so, the perhaps it should live
> in fail_over_srv.c.  I'm a bit unclear as to how this might be implemented
> in the fail_over_srv "plugin".  The fo_discover_srv_* functions have a
> resolv_ctx available to them, but it would seem neater to have a dedicated
> fo_discover_ctx structure to store the configuration, along with the sticky
> ldap server name.

My initial idea was to create a wrapper around resolv_sort_srv_reply()
that would take the previous server and optionally a flag parameter.

Then, if the previous server was present and the flags would indicate
that the server should be preferred, it would just be moved to the 1st
place in the list. The previous server would probably have to be kept
somewhere in the fail over code, maybe struct fo_ctx could be used?

If course, fo_discover_ctx could also be used, did you think about
creating it as a member of fo_ctx, maybe created during
fo_set_srv_lookup_plugin() ?
___
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://getfedora.org/code-of-conduct.html
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: sssd: AD service discovery and invalidating cache

[Jakub Hrozek]

On Fri, Jan 04, 2019 at 09:20:20AM +, R Davies wrote:
> (re-sending as I initially sent to ssd-users-owners in error)
> 
> For an AD environment using service discovery.
> 
> Periodically sssd will invalidate its cache at unexpected times.  Digging
> around debug logs and sources leads me to understand the following:
> 
> Every 15 minutes (or as defined by ldap_connection_expire_timeout) sssd
> re-establishes the connection to LDAP, closing the exiting collection.
> When sssd is configured to auto discover (via DNS _srv_ records, where the
> priority is the same for each server); auto-discovery might return a
> different LDAP server, at which point sssd's stored uSNChanged values are
> invalid (as these are unique to each server), the cached values are
> cleared, and enumeration is run - essentially afresh - against the new LDAP
> server.

Thank you very much for digging into the issue.

> 
> Is this outcome expected by design?

Honestly, I'm not sure and I would like some other developers to chime
in with their opinion.

Historically, we've said that SSSD should stick to a 'working' server as
long as it can, so on one hand I see the point in the sticky behaviour.
On the other hand, I've also seen admins relying on the TTL validity of
the SRV records, expecting that, if they change the SRV records, the
client chooses a new server after the TTL expires.

> 
> This behaviour is rather unfortunate as sssd_be will become CPU hog as it
> rebuilds the cache again.
> 
> It is possible to work around the behaviour e.g.:
> 
> 1) by not using service discovery, i.e.

Yes, in this case, the same server will always be selected from the
list, working around the problem.

> 
> ad_server = server1
> ad_backup = server2
> 
> which is fairly tiresome to maintain across an estate - separate
> configurations for different sites etc, faking load balancing by swapping
> configurations.
> 
> 2) having different priorities for each AD server in a given site, losing
> load balancing - unless DNS gave out different priorities depending on the
> source of the request, but this seems messy.
> 
> A better approach might be to patch sssd's auto discovery to "stick" to the
> previously bound LDAP server, currently the first server in the list of
> primary servers returned by ad_sort_servers_by_dns().  I have a proof of
> concept patch that is straight forward, and fairly well contained, the
> behaviour is controlled by an ad_sticky option in sssd.conf.
> 
> Is there a better solution to this problem?   Would a patch - as vaguely
> outlined above - likely gain acceptance?

If the behaviour is controllable by an option, my opinion is that it
would be a good approach.

Would the stickiness also persist across SRV priority levels? What I
mean is that if server1 had originally the highest priority (the lowest
priority value in the SRV record), but then the SRV record is expired
and the server is suddendly in a lower priority tier, IMO then the server
should be 'forgotten' and a new one chosen..
___
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://getfedora.org/code-of-conduct.html
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: sssd database backup / restore (or transplant to another client)

[Jakub Hrozek]

On Thu, Jan 03, 2019 at 10:01:47AM +0200, Nikos Zaharioudakis wrote:
> Good morning list,
> 
> I have an idea, which I would like to experiment with, but experts
> advise may save me lots of time.
> 
> The scenario I have in mind is like this:
> 
> (assume OS and vers are latest RHEL/Centos)
> 
> I join a client to an IPA server. After joining, in the
> /var/lib/sss/db/ directory, a database per domain is expected. (or
> perhaps populated after the first request to the IPA server for
> example id some-username)
> 
> Now the question is:
> If I stop the sssd client service, may I copy the content of this
> directory to another client (which is already registered as well to
> the same IPA server) and save some time from the initial database
> population?
> You may say that this operation is not time-consuming etc, but in my
> case, I have to spin up some thousands of machines as fast as possible
> which are practically diskless. Meaning that the whole party has to
> happen as fast as possible and at the end, I have a ddos attack
> against my IPA servers and their replicas with a boom of (let's say)
> 3K clients asking more or less the same things (mostly ldap
> verification queries).

This is an interesting use-case we've seen a couple of times in diskless
clusters. We've also pondered the idea of 'priming' the cache, but AFAIK
so far nobody did this
> 
> So a first question to address my situation would be: Is the sssd db
> unique per client or may I "transplant" it to other clients as well?

Some parts of the database are unique to the client, especially in IPA
or AD cases, some can be copied.

If you install the ldb-tools package (in RHEL this is AFAIK in the
Optional channel), then you can inspect the cache with:
ldbsearch -H /var/lib/sss/db/cache_XXX
and:
ldbsearch -H /var/lib/sss/db/timestamps_

You'll see containers for users, groups, but also HBAC rules, ID
overrides and other data.

If you don't use ID overrides, then I guess it might be possible to
extract the user and group objects from the cache using ldbsearch and
add them to a 'new' cache with ldbadd/ldbmodify before starting the
node. It might be a good idea to also add the timestamps from the
timestamp cache to save the initial disk write. On the other hand, you
should not copy the whole cache as you might also copy HBAC rules meant
for another client. In theory this /should/ be OK as the HBAC rules are
refreshed on every access attempt (with a small timeout), but in case
the access was attempted offline, you could have run into the situation
where the cached rules meant for another client are evaluated.

btw the reason the timestamps are stored in a separate ldb file is that
the timestamp ldb file is opened in async mode, meaning a write does not
cause an fsync and the cache writes are buffered by the OS. This means
the cache writes are much faster, but in the odd case sssd crashed
before the buffers were flushed, the database might be inconsistent. So
we only use this fast mode for attributes that change often, like
timestamps, that change on every db write.

I think this is an interesting experiment, please let us know how it
goes.
___
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://getfedora.org/code-of-conduct.html
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: Can I have sssd manage known_hosts with LDAP?

[Jakub Hrozek]

On Mon, Dec 10, 2018 at 01:19:33PM -, George Diamantopoulos wrote:
> Thanks for the reply Jakub.
> 
> Does this mean that there is no support in 1.15 at all, or that the attribute 
> name is hardcoded as "fqdn" but still useable if the schema complies?

There is no support at all, the sss_ssh_knownhosts proxy has no
'handler' on the sssd_be side to talk to.
___
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://getfedora.org/code-of-conduct.html
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: Problem with resolving unqualified group names

[Jakub Hrozek]

On Fri, Nov 23, 2018 at 10:16:26AM +, Ondrej Valousek wrote:
> Hi List,
> 
> 
> I have noticed that in my case both
> 
> getent passwd @ and getent passwd 
> 
> works, but
> 
> getent group @
> 
> does not, only:
> 
> getent group 
> 
> works.
> 
> 
> Is that expected behavior?

No (but I don't know what else to add except worksforme..)
___
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://getfedora.org/code-of-conduct.html
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: sssd AD authentication working; sssd autofs against LDAP / rfc2307bis not working...

[Jakub Hrozek]

On Wed, Dec 05, 2018 at 12:28:18PM -0600, Spike White wrote:
> Sssd experts,
> 
> This is all on RHEL7.
> 
> I have sssd properly authenticating against AD for my multi-domain forest.
> All good – even cross-domain auth (as long as I don’t use tokengroups.)
> Our company’s AD implementation is RFC2307bis schema-extended.
> 
> Now – for complicated reasons – I’m told I need to get nis automaps and nis
> netgroups in AD and also working on the clients (via sssd) also.
> 
> As a first testing step, I’ve stood up an openLDAP server on another RHEL7
> server.  And schema extended it with RFC 2307 bis.
> 
> http://bubblesorted.raab.link/content/replace-nis-rfc2307-rfc2307bis-schema-openldap
> 
> I added an initial automap.
> 
> When I query via ldapsearch, all looks good:
> 
> [root@spikerealmd02 sssd]# ldapsearch -LLL -x -H ldap://
> austgcore17.us.example.com -b 'ou=automount,ou=admin,dc=itzgeek,dc=local'
> -s sub -D 'cn=ldapadm,dc=itzgeek,dc=local' -w ldppassword
> 'objectClass=automountMap'
> 
> dn: automountMapName=auto.master,ou=automount,ou=admin,dc=itzgeek,dc=local
> 
> objectClass: top
> 
> objectClass: automountMap
> 
> automountMapName: auto.master
> 
> 
> 
> dn: automountMapName=auto.home,ou=automount,ou=admin,dc=itzgeek,dc=local
> 
> objectClass: top
> 
> objectClass: automountMap
> 
> automountMapName: auto.home
> 
> 
> 
> [root@spikerealmd02 sssd]# ldapsearch -LLL -x -H ldap://
> austgcore17.us.example.com -b 'ou=automount,ou=admin,dc=itzgeek,dc=local'
> -s sub -D 'cn=ldapadm,dc=itzgeek,dc=local' -w ldppassword
> 'objectClass=automount'
> 
> dn:
> automountKey=/home2,automountMapName=auto.master,ou=automount,ou=admin,dc=
> 
>  itzgeek,dc=local
> 
> objectClass: top
> 
> objectClass: automount
> 
> automountKey: /home2
> 
> automountInformation:
> ldap:automountMapName=auto.home,ou=automount,ou=admin,dc
> 
>  =itzgeek,dc=local --timeout=60 --ghost
> 
> 
> 
> dn:
> automountKey=/,automountMapName=auto.home,ou=automount,ou=admin,dc=itzgeek
> 
>  ,dc=local
> 
> objectClass: top
> 
> objectClass: automount
> 
> automountKey: /
> 
> automountInformation:
> -fstype=nfs,rw,hard,intr,nodev,exec,nosuid,rsize=8192,ws
> 
>  ize=8192 austgcore17.us.example.com:/export/&
> 
> 
> 
> [root@spikerealmd02 sssd]#
> 
> 
> 
> Next, the sssd client configuration.
> 
> In my good sssd client’s sssd.conf file, I added “autofs” to my services
> line and added an “autofs” section.  That is,  I have changed my
> /etc/sssd/sssd.conf file as so:
> 
> [sssd]
> 
> …
> 
> services = nss,pam,autofs
> 
> …
> 
> [autofs]
> 
> debug_level = 9

All the options below should be specified in the domain section, not the
autofs section. The autofs responder only talks to the automounter
'client' (e.g. when you run automount -m), not to LDAP. The only process
in SSSD that ever talks to LDAP is sssd_be.

Running automount -m is also IMO a good way to test the config.

> 
> autofs_provider = ldap
> 
> ldap_uri= ldap://austgcore17.us.example.com
> 
> ldap_schema = rfc2307bis
> 
> ldap_default_bind_dn = cn=ldapadm,dc=itzgeek,dc=local
> 
> ldap_default_authtok = ldppassword
> 
> ldap_autofs_search_base = ou=automount,ou=admin,dc=itzgeek,dc=local
> 
> ldap_autofs_map_object_class = automountMap
> 
> ldap_autofs_map_name = automountMapName
> 
> ldap_autofs_entry_object_class = automount
> 
> ldap_autofs_entry_key = automountKey
> 
> ldap_autofs_entry_value = automountInformation
> 
> 
> 
> [nss]
> 
> debug_level = 9
> 
> 
> 
> I appended sss to automount line in /etc/nsswitch.conf file:
> 
> 
> 
> automount:  files sss
> 
> 
> 
> 
> 
> Yet, when I try to restart autofs service it (eventually) times out:
> 
> 
> 
>  [root@spikerealmd02 sssd]#  systemctl restart sssd
> 
> [root@spikerealmd02 sssd]# systemctl restart autofs
> 
> Job for autofs.service failed because a timeout was exceeded. See
> "systemctl status autofs.service" and "journalctl -xe" for details.
> 
> 
> 
> Journalctl –xe reports this:
> 
> 
> 
> Dec 03 11:14:09 spikerealmd02.us.example.com [sssd[ldap_child[9653]]][9653]:
> Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]:
> Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection.

The domain log would tell you more, i.e. what principal did sssd_be try
to authenticate, but the tl;dr is that sssd_be couldn't authenticate to
the LDAP server.

> 
> …
> 
> Dec 03 11:14:15 spikerealmd02.us.example.com [sssd[ldap_child[9680]]][9680]:
> Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]:
> Preauthentication faile
> 
> Dec 03 11:14:22 spikerealmd02.us.example.com systemd[1]: autofs.service
> start operation timed out. Terminating.
> 
> Dec 03 11:14:22 spikerealmd02.us.example.com systemd[1]: Failed to start
> Automounts filesystems on demand.
> 
> -- Subject: Unit autofs.service has failed
> 
> -- Defined-By: systemd
> 
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 
> --
> 
> -- Unit autofs.service has failed.
> 
> --
> 
> -- The result is failed.

[SSSD-users] Re: Can I have sssd manage known_hosts with LDAP?

[Jakub Hrozek]

On Sat, Dec 08, 2018 at 08:09:09PM +0200, George Diamantopoulos wrote:
> User ssh public key retrieval works fine in my configuration. I'm using
> sssd 1.15 which ships with debian stretch.

I'm afraid the commit that exposed the host key lookup to the LDAP
provider is only present in 1.16.1 and newer.
___
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://getfedora.org/code-of-conduct.html
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: sssd with sudo and non posix groups

[Jakub Hrozek]

On Wed, Nov 14, 2018 at 09:45:23AM -0800, Leonard Lawton wrote:
> On 11/14/2018 12:28 AM, Jakub Hrozek wrote:
> > On Tue, Nov 13, 2018 at 05:00:56PM -0800, Leonard Lawton wrote:
> > > I have a group in ldap(I'm using 389DS) called "_all" which has a
> > > groupofnames object class. Members are stored with the uniquemember
> > > attrtibute. The users in the group are able to login fine via ssh using 
> > > this
> > > setup. However, I can't seem to figure out how to get sudo(via ldap) to 
> > > work
> > > with my needs.
> > > The problem seems to be that I am using uniquemember which my 
> > > configuration
> > > is not interpreting. I can't use rfc2307 and fall back to posix groups(and
> > > memberUID) only as I rely heavily on the groupofnames's functionality, so 
> > > I
> > > really need to keep that. How can I configure sssd to let me use sudo 
> > > while
> > > having a groupofnames as an authoritative source?
> > Do the groups have a gidNumber? I assume not, otherwise you'd probably
> > create the groups with the posixGroup objectclass as well.
> They do have a gidNumber and have both posixGroup and groupofnames object
> classes.

Do they show up in the id output?

> > 
> > In general, I don't think sudo allows this, because sudo calls
> > getgrouplist(3) to see which groups the user belongs to and this call,
> > being POSIX only returns POSIX groups.
> > 
> > The schema (rfc2307 vs rfc2307bis) is not really relevant, what is
> > relevant is that the groups must be visible on the OS level, e.g. with
> > the id(1) call. I guess one way to go might be to create a POSIX group
> > (sudo_allowed) and add the _all group as a member of this sudo_allowed
> > group?
> The rfc2307 vs rfc2307bis comes into play as the group members have
> different attributes in posix vs groupofnames
> 
> Example membership of group _all when populating with posixGroup
> attritbutes:
> memberUid: bob

posixGroup does not imply memberUid, does it?

> 
> Example membership of group _all when populating with groupofnames
> attritbutes:
> uniqueMember: uid=bob,dc=something
> 
> sssd will never seem to allow memberUid /and/ uniqueMember to be searched as
> group membership.

yes, with ldap_schema=rfc2307bis, only 'member: $dn' is used by default by
SSSD. btw it looks like your configuration doesn't override the
ldap_group_member option, so I guess the uniqueMember attribute is not
used?

> > > Here is my config:
> > > 
> > > [domain/dingos]
> > > ldap_schema = rfc2307bis
> > > ldap_group_search_base = dc=dingos?sub?
> > > ldap_user_search_base = ou=people,dc=dingos
> > > ldap_uri = ldaps://ldap-server
> > > ldap_tls_cacertdir = /etc/openldap/cacerts
> > > sudo_provider = ldap
> > > ldap_access_filter = (|(memberof=cn=_all,ou=hosts,ou=roles,dc=dingos))
> > > id_provider = ldap
> > > auth_provider = ldap
> > > chpass_provider = ldap
> > > cache_credentials = false
> > > access_provider = ldap
> > > debug_level = 0x3ff0
> > > ldap_sudo_search_base = ou=SUDOers,ou=roles,dc=dingos
> > > entry_cache_timeout = 1
> > > 
> > > [sssd]
> > > config_file_version = 2
> > > services = nss, pam, sudo
> > > domains = dingos
> > > ___
> > > 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://getfedora.org/code-of-conduct.html
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: 
> > > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > ___
> > 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://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> 
> 

> ___
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
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://getfedora.org/code-of-conduct.html
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: SSSD in AIX

[Jakub Hrozek]

On Mon, Nov 12, 2018 at 05:24:54PM +0530, Ayappan wrote:
> On Mon, Nov 12, 2018 at 4:56 PM Jakub Hrozek  wrote:
> >
> > On Mon, Nov 12, 2018 at 03:57:53PM +0530, Ayappan wrote:
> > > Hi,
> > >
> > > I am from AIX OS development team here in IBM. We have some customers
> > > who are interested in running SSSD in AIX. So i basically invested
> > > some amount of time to first build SSSD in AIX. I built the recent
> > > version 1.16.3 after working around some build issues. Below is the
> > > configure options.
> > > ./configure --prefix=/opt/freeware --disable-cifs-idmap-plugin
> > > --without-nfsv4-idmapd-plugin --disable-rpath --with-manpages=no
> > > --without-python3-bindings --with-selinux=no --with-semanage=no
> > > --with-crypto=libcrypto --without-secrets --without-kcm
> > >
> > > I started the daemon but then it failed later with no stderr / logs
> > > produced anywhere.
> > >
> > > # /opt/freeware/sbin/sssd -i -d4
> >
> > Are there also no messages if you run with -d 10 ?
> >
> 
> I just ran it and attached the output. It is showing lot of messges
> with "ldb" tag. Not sure how to interpret it.

Hmm, this is strange, for some reson the ldb library debug hooks work,
but not the sssd debugging itself? I don't know what to make of it
because both should be routed to the sss_vdebug_fn() function. I guess
it should be possible to gdb the monitor process and see what gets
called e.g. inside server_setup() when one of the DEBUG messages is
reached?

> 
> > On Linux, I would have said that strace with -ff would be also helpful,
> > but I have no idea if something like this exists on AIX.
> >
> 
> AIX strace seems to be different. But it has truss command which is
> similar to Linux strace. Just ran that as well. It provides
> good deal of info. Seems like i need to analyze the output to make out
> anything meaningful.
> 
> > >
> > > (1) root @ fvt-p7a2-lp16: /
> > >
> > > I see it invokes two other child process which also failed
> > > /opt/freeware/libexec/sssd/sssd_be --domain implicit_files --uid 0
> > > --gid 0 -d 0x01f0 --logger=stderr
> > > /opt/freeware/libexec/sssd/sssd_nss --uid 0 --gid 0 -d 0x01f0 
> > > --logger=stderr
> > >
> > > Any help would be appreciated.
> > >
> > > Thanks
> > > Ayappan P
> > > ___
> > > 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://getfedora.org/code-of-conduct.html
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: 
> > > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > ___
> > 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://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

> _poll(0x20057788, 4, 1928)  = 4
> _enrecvmsg(10, 0x2FF22358, 0, 0x)   = 1
> getpeereid(10, 0x2FF22380, 0x2FF2237C)  Err#76 ENOTCONN
> kread(10, " A U T H   E X T E R N A".., 2048)   = 18
> _poll(0x20057788, 4, 1926)  = 4
> _esend(10, 0x200575F8, 46, 256, 0x) Err#32 EPIPE
> Received signal #20, SIGCHLD [caught]

Here the child process (sssd_be) tries to connect to the sssd main
processes' D-Bus socket, sends the AUTH EXTERNAL command to try to
authenticate, but when the sssd tries to reply, the send
call returns EPIPE..this indicates the sssd_be process is exiting after
startup.

I can't tell from the truss output what makes the sssd_be fail. It would
be best to first figure out why the logger is not working..
___
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://getfedora.org/code-of-conduct.html
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: sssd with sudo and non posix groups

[Jakub Hrozek]

On Tue, Nov 13, 2018 at 05:00:56PM -0800, Leonard Lawton wrote:
> I have a group in ldap(I'm using 389DS) called "_all" which has a
> groupofnames object class. Members are stored with the uniquemember
> attrtibute. The users in the group are able to login fine via ssh using this
> setup. However, I can't seem to figure out how to get sudo(via ldap) to work
> with my needs.
> The problem seems to be that I am using uniquemember which my configuration
> is not interpreting. I can't use rfc2307 and fall back to posix groups(and
> memberUID) only as I rely heavily on the groupofnames's functionality, so I
> really need to keep that. How can I configure sssd to let me use sudo while
> having a groupofnames as an authoritative source?

Do the groups have a gidNumber? I assume not, otherwise you'd probably
create the groups with the posixGroup objectclass as well.

In general, I don't think sudo allows this, because sudo calls
getgrouplist(3) to see which groups the user belongs to and this call,
being POSIX only returns POSIX groups.

The schema (rfc2307 vs rfc2307bis) is not really relevant, what is
relevant is that the groups must be visible on the OS level, e.g. with
the id(1) call. I guess one way to go might be to create a POSIX group
(sudo_allowed) and add the _all group as a member of this sudo_allowed
group?

> 
> Here is my config:
> 
> [domain/dingos]
> ldap_schema = rfc2307bis
> ldap_group_search_base = dc=dingos?sub?
> ldap_user_search_base = ou=people,dc=dingos
> ldap_uri = ldaps://ldap-server
> ldap_tls_cacertdir = /etc/openldap/cacerts
> sudo_provider = ldap
> ldap_access_filter = (|(memberof=cn=_all,ou=hosts,ou=roles,dc=dingos))
> id_provider = ldap
> auth_provider = ldap
> chpass_provider = ldap
> cache_credentials = false
> access_provider = ldap
> debug_level = 0x3ff0
> ldap_sudo_search_base = ou=SUDOers,ou=roles,dc=dingos
> entry_cache_timeout = 1
> 
> [sssd]
> config_file_version = 2
> services = nss, pam, sudo
> domains = dingos
> ___
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
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://getfedora.org/code-of-conduct.html
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: SSSD login delay

[Jakub Hrozek]

On Mon, Nov 12, 2018 at 04:25:30PM -, Jonathan Gray wrote:
> Hello,
> 
> We need help debugging this issue.
> 
> For some servers we're experiencing over 10 second delay logging in with IPA 
> user.
> Since the issue isn't present everywhere we're finding it hard to debug.
> 
> 
> SSSD config looks like this::
> 
> [domain/hostname.com]
> 
> cache_credentials = true
> krb5_store_password_if_offline = true
> ipa_domain = hostname.com
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ldap_tls_cacert = /etc/ipa/ca.crt
> ipa_hostname = hostname.com
> chpass_provider = ipa
> dyndns_update = True
> ipa_server = ipa1-hostname, ipa2-hostname
> dyndns_iface = eth0
> dns_discovery_domain = hostname.com
> debug_level = 9
> 
> [sssd]
> services = nss, sudo, pam, ssh
> 
> domains = hostname.com
> [nss]
> homedir_substring = /home
> 
> [pam]
> 
> [sudo]
> 
> [autofs]
> 
> [ssh]
> 
> [pac]
> 
> [ifp]
> 
> [secrets]
> 
> [session_recording]
> 
> We're wondering if there's any obvious configurations we could apply above 
> that would improve SSSD performance

There's no make_sssd_faster=True switch :-), it's hard to give an advise
without at least a little understanding of what might be the root cause.

In general, login consists of:
- retrieving the user information
- you can simulate the worst case by running "sss_cache -E; id
  $username". Above you said that the user is an IPA one, does the
  user really come from the IPA directory or e.g. IPA-AD trusts? The
  difference would be that with IPA, the sssd on the clients talks
  directly to the IPA directory server, with IPA-AD trusts the SSSD on
  the clients talks to the DS on the IPA servers which ask SSSD on the
  servers which ask the AD DS.  So in the trust case, typically you want
  to first make sure the servers are fast. If this is the slow piece,
  then look into the SSSD logs for messages like dp_get_account_info_send
  (this is the beginning of a lookup) and dp_req_reply_std (this is
  the end of a lookup). Are there many of these messages or is there
  a long delay between them? Some time ago we also instrumented the
  SSSD code with systemtap probes, so maybe it would be easier to
  run a systemtap script and see what is slow, e.g.
  
http://justin-stephenson.blogspot.com/2017/05/measuring-sssd-performance-with.html

- authentication
- you can simulate the SSSD authentication /partially/ with
  kinit. But SSSD also does some extra steps like verifying the
  TGT comes from the same KDC that issued the keytab. But all in
  all you can look for messages like dp_pam_handler_send for the
  pam request beginning and dp_req_done for PAM request end.

- authorization
- similar to above, dp_pam_handler_send followed by
  SSS_PAM_ACCT_MGMT marks the beginning of the account control check
  and dp_req_done marks the account check end

- session setup
- unless you use FleetCommander to control your desktop systems,
  SSSD typically does nothing in this step

>, and what exactly to look out for in sssd debug logs that would help us with 
>our investigation.

I'd advise to experiment with the lookups, kinit and check the systemtap
scripts or check which PAM phase might be slow for you.

Also, if you have many groups or especially many large groups, it might
be worth a try to suppress group members (ignore_group_members=True)
___
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://getfedora.org/code-of-conduct.html
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: SSSD in AIX

[Jakub Hrozek]

On Mon, Nov 12, 2018 at 03:57:53PM +0530, Ayappan wrote:
> Hi,
> 
> I am from AIX OS development team here in IBM. We have some customers
> who are interested in running SSSD in AIX. So i basically invested
> some amount of time to first build SSSD in AIX. I built the recent
> version 1.16.3 after working around some build issues. Below is the
> configure options.
> ./configure --prefix=/opt/freeware --disable-cifs-idmap-plugin
> --without-nfsv4-idmapd-plugin --disable-rpath --with-manpages=no
> --without-python3-bindings --with-selinux=no --with-semanage=no
> --with-crypto=libcrypto --without-secrets --without-kcm
> 
> I started the daemon but then it failed later with no stderr / logs
> produced anywhere.
> 
> # /opt/freeware/sbin/sssd -i -d4

Are there also no messages if you run with -d 10 ?

On Linux, I would have said that strace with -ff would be also helpful,
but I have no idea if something like this exists on AIX.

> 
> (1) root @ fvt-p7a2-lp16: /
> 
> I see it invokes two other child process which also failed
> /opt/freeware/libexec/sssd/sssd_be --domain implicit_files --uid 0
> --gid 0 -d 0x01f0 --logger=stderr
> /opt/freeware/libexec/sssd/sssd_nss --uid 0 --gid 0 -d 0x01f0 --logger=stderr
> 
> Any help would be appreciated.
> 
> Thanks
> Ayappan P
> ___
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
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://getfedora.org/code-of-conduct.html
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: Id vs ldapsearch

[Jakub Hrozek]

On Tue, Nov 06, 2018 at 05:22:52PM -0500, Tom wrote:
> Just a general question about the behaviour of sss_cache , is and ldapsearch.
> 
> Id will return say 8 groups and for the same user ldapsearch will return 10.
> 
> Now as long as if returns 8 apps report authentication denied because the 
> user is not in an expected group.  Now when we run sss_cache -E to invalidate 
> the cache, id Will now return all 10 groups.
> 
> Now the group change was done days ago and our entry_cache_timeout is at 
> default of 5400.
> 
> Why do we still need to run sss_cache -E if the timeout should take care of 
> things?  We are directly authenticated against AD via computer objects.  
> 
> Just asking a general question as I’m curious how this works.  

Sounds like an issue, can you capture it with logs?
___
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://getfedora.org/code-of-conduct.html
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: Ubuntu Bionic - sssd 1.16.1 - kerberos ticket not renewing

[Jakub Hrozek]

On Thu, Nov 01, 2018 at 05:20:57PM +, Jay McCanta wrote:
> I have the snippets.  May I mail them to you directly.  I was trying to 
> cleanse them, but I'm afraid I'm changing them too much.  

Yes, sure.
___
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://getfedora.org/code-of-conduct.html
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: Ubuntu Bionic - sssd 1.16.1 - kerberos ticket not renewing

[Jakub Hrozek]

On Wed, Oct 31, 2018 at 08:20:55PM +, Jay McCanta wrote:
> Yes.  Kinit -R renews the ticket (if it hasn't expired).

OK, can you attach a snippet of the logs? I thiknk the domain log and
the krb5_child.log are the most important.
___
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://getfedora.org/code-of-conduct.html
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: Default user quotas with SSSD

[Jakub Hrozek]

On Fri, Oct 19, 2018 at 12:26:28AM -0400, TomK wrote:
> Does SSSD allow setting quotas for existing or newly authenticated users?

No. We've talked with the systemd developers about the possibility of
sssd fetching cgroups limits from LDAP and passing them on to
pam_systemd.so to set limits on processes. IIRC the person who
originally requested this was a university admin who wanted to restrict
what the students can and can't do on the machines centrally.

But it's not implemented yet.
___
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://getfedora.org/code-of-conduct.html
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: Ubuntu Bionic - sssd 1.16.1 - kerberos ticket not renewing

[Jakub Hrozek]

On Wed, Oct 31, 2018 at 07:19:44PM +, Jay McCanta wrote:
> I have a new server running Ubuntu Bionic (18.04.01) with sssd 
> 1.16.1-1ubuntu1.  The problem is that our Kerberos tickets are not being 
> renewed while we are logged in.  I have tried using FILE and KEYRING 
> credential caches.  SSH has Kerberos disabled, GSSAPI disabled, and is 
> configured to use PAM.  Logging works, but the ticket expires without being 
> renewed. We are using sssd-ad for auth.   I've cranked up the debug to level 
> 9.  I am unsure where to start to try to troubleshoot.  Advice is appreciated.
> 
> Jay McCanta
> F5 Networks, Inc.
> 
> Here's a sample ticket:
> 
> Ticket cache: KEYRING:persistent:27644:krb_ccache_pBjYhsU
> Default principal: mccanta-ad...@olympus.f5net.com
> 
> 10/31/2018 16:15:51  11/01/2018 02:15:51  krbtgt/example@example.com
>   renew until 11/07/2018 16:15:51

Can you renew the ticket with kinit -R ?

> 
> /etc/sssd/sssd.conf (ad_access_filter omitted for security):
> [sssd]
> config_file_version = 2
> domains = example.com
> services = nss, pam
> debug_level = 9
> reconnection_retries = 3
> 
> [nss]
> debug_level = 9
> 
> [pam]
> debug_level = 9
> 
> [domain/example.com]
> debug_level = 9
> id_provider = ad
>   default_ccache_tempate=KEYRING:persistent:%U
>   krb5_renewable_lifetime=10d
>   krb_renew_interval=2h
>   auth_provider = ad
> access_provider = ad
> ldap_id_mapping = False
> ad_gpo_access_control = permissive
> 
> Krb5.conf:
> [libdefaults]
>   default_realm = EXAMPLE.COM
>   dns_lookup_realm = true
>   dns_lookup_kdc = true
>   ticket_lifetime = 24h
>   renew_lifetime = 7d
>   rdns = false
>   forwardable = yes
> default_ccache_name=KEYRING:persistent:%{uid}
> 
> [realms]
>   EXAMPLE.COM = {
>  default_domain = example.com
>#site=SE3CIP
>kdc=dc01.example.com:88
>kdc=dc02.example.com:88
>   }
> 
> [domain_realm]
>   example.com = EXAMPLE.COM
>   .example.com = EXAMPLE.COM

> ___
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
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://getfedora.org/code-of-conduct.html
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: sssctl & InfoPipe

[Jakub Hrozek]

> On 10 Oct 2018, at 14:04, Ondrej Valousek  wrote:
> 
> Hi list.
>  
> When I run 
> # sssctl user-checks 
> The command will,  under the “SSSD InfoPipe user lookup result” section:
> -  Print some information no matter if I enable InfoPipe in the 
> configuration or not
> -  When I enable [ifp] and add an extra attributes, such as 
> “user_attributes = +mail, +telephoneNumber, +givenname, +sn”, they does not 
> appear in the sssctl output as per above
> Is it intentional behavior?

As you found out, it’s sort of a missing feature. Thanks for filing the bug, it 
should be possible to fix that.

>  
> Thanks,
> Ondrej
> -
> 
> The information contained in this e-mail and in any attachments is 
> confidential and is designated solely for the attention of the intended 
> recipient(s). If you are not an intended recipient, you must not use, 
> disclose, copy, distribute or retain this e-mail or any part thereof. If you 
> have received this e-mail in error, please notify the sender by return e-mail 
> and delete all copies of this e-mail from your computer system(s). Please 
> direct any additional queries to: 
> communicati...@s3group.com. Thank You. Silicon and Software Systems Limited 
> (S3 Group). Registered in Ireland no. 378073. Registered Office: South County 
> Business Park, Leopardstown, Dublin 18.
> ___
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org