Re: [SSSD-users] Empty groups with sssd 1.9.4

[Pavel Březina]

On 02/17/2013 05:33 PM, Michael Ströder wrote:

HI!

We're running Debian systems with old sssd 1.2.1 shipped in Debian Squeeze.
This works most of the times with getent passwd and getent group together with
uncached sudo-ldap data. So the data is in place and can be correctly
retrieved by sssd via LDAP.

Since this old sssd version has some problems and does not have SUDO support
we're looking at upgrading to 1.9.4.

My colleague prepared back-ported Debian packages of 1.9.4 I'm testing with.

But I'm struggling that groups are not correctly retrieved - see my last
attempt of sssd.conf attached.

1. After login id does not show the user's groups although the OpenLDAP logs
show that group entries are searched and returned to sssd by OpenLDAP's slapd.

2. sudo -l -U username does not work although the OpenLDAP logs show that
sudoRole entries are searched and returned to sssd by OpenLDAP's slapd.

I wonder whether https://fedorahosted.org/sssd/ticket/1664 is relevant in my
case but playing with several values for filter_users_in_groups and enumerate
did not help.

Ciao, Michael.


Hi,
can you raise debug level in nss, sudo and domain section to 9 (put 
debug_level = 9 in [nss], [sudo] and [domain/yourdomain] sections in 
sssd.conf? What does the logs say?


Thanks,
Pavel.

___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Empty groups with sssd 1.9.4

[Pavel Březina]

On 02/20/2013 09:39 PM, Michael Ströder wrote:

Jakub Hrozek wrote:

Feel free to ping this list again if you
can't get the sudo integration working. Please note you need relatively
recent sudo built with the --with-sssd (not sure if Debian would do that
even in -unstable/-testing)


Aah, this is a good hint where to look. And yes, I couldn't get it to work
under Debian Squeeze.

Could you please provide the minimum sudo version required?


1.8.6rc1


___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sss_ssh_authorizedkeys returns "Error looking up public keys"

[Pavel Březina]

On 03/19/2013 08:05 PM, Mathieu Lemoine wrote:

2013/3/19 Jakub Hrozek mailto:jhro...@redhat.com>>

On Tue, Mar 19, 2013 at 07:15:21PM +0100, Jakub Hrozek wrote:
 > On Tue, Mar 19, 2013 at 01:56:20PM -0400, Mathieu Lemoine wrote:
 > > Hello,
 > >
 > > I have sssd 1.9.4 (from
 > > https://launchpad.net/~nicholas-hatch/+archive/auth/+packages)
configured
 > > on an OpenLDAP server.
 > > getent passwd, getent group, authentication and cache is
working great.
 > >
 > > My issue now lies with the SSH public key.
 > >
 > > My user has the ldapPublicKey objectClass, and the key is in the
 > > sshPublicKey attribute.
 > >
 > > sss_ssh_authorizedkeys is still returning "Error looking up
public keys".
 > > An inquiry on the #sssd chan directed me to this mailing-list
and more
 > > precisely to jcholast, I tried to check out the commits, but
nothing seems
 > > to get out of it...
 >
 > Full disclosure: I was the one who redirected Mathieu to you,
Honza :-)
 >
 > >
 > > If any of you had informations regarding that, it'd be greatly
appreciated.,
 > > Mathieu.
 >
 > I think as a first step, it would be nice to put debug_level=8
into the
 > [ssh] section of the sssd.conf file, restart the SSSD and then attach
 > the ssh responder logs (/var/log/sssd/sssd_nss.log).

  
Sorry, this is a copy-n-paste error. The *ssh* responder log is located
at:
/var/log/sssd/sssd_ssh.log

The path I copied was the *nss* responder log. Sorry again.

Ok, so first point, I didn't know I needed a sss responder for ssh (not
mentionned anywhere as far as I know). Thanks for this.
I added ", ssh" to the "services" line and restarted sssd.

sss_ssh.log stays hopelessly empty even with debug_level 10 and I still
have the sshPublicKey is not available in sss_office.log

However sss_ssh_authorizedkeys now doesn't return any error, just a big
nothing...

Attached is the ldif of my user (I removed any sensitive information,
anyway, the entry has been fetched using anonymous access, so passwords
and such has been left aside.



id_provider = ldap
auth_provider = ldap
chpass_provider = ldap


Hi,
I'm afraid we support ssh keys only with IPA backend at the moment.

___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sss_ssh_authorizedkeys returns "Error looking up public keys"

[Pavel Březina]

On 03/20/2013 01:16 PM, Jakub Hrozek wrote:

On Wed, Mar 20, 2013 at 08:12:33AM -0400, Simo Sorce wrote:

On Wed, 2013-03-20 at 10:19 +0100, Pavel Březina wrote:


Hi,
I'm afraid we support ssh keys only with IPA backend at the moment.



Should we open a RFE to make it available with other backends too ?



This is already part of https://fedorahosted.org/sssd/ticket/1560 it
seems:

"""
In the LDAP provider, ldap_user_ssh_public_key has no default value.
Make sshPublicKey the default value for it, so that OpenSSH-LPK support
is enabled by default.
"""


This sounds more like it should work with LDAP provider if you set
ldap_user_ssh_public_key to sshPublicKey. But we don't have any support
whatsoever. We lack sssm_ldap_hostid_init().
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd and ldap based sudoers

[Pavel Březina]

On 07/19/2013 11:03 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network 
Support) wrote:

Having asked thatI just found the man page  sudoers.ldap

I'll read on before asking more stupid questions.

Al


Hi,
the information on configuring sudo to work with sssd can be found in 
sssd-sudo manual page. To summarize it you need to:


1. put "sudoers: files sss" in /etc/nsswitch.conf
2. edit sssd.conf
 - [sssd]/services contains "sudo"
 - [domain/yourdomain]/sudo_provider = ldap
 - more configuration depends whether you use pure ldap or ipa/ad, see 
man sssd-sudo


You do not have to configure ldap.conf.



-Original Message-
From: sssd-users-boun...@lists.fedorahosted.org 
[mailto:sssd-users-boun...@lists.fedorahosted.org] On Behalf Of Ondrej Valousek
Sent: Friday, July 19, 2013 12:18 PM
To: End-user discussions about the System Security Services Daemon
Subject: Re: [SSSD-users] sssd and ldap based sudoers

That said, the sudoers.ldap file needs to be updated to refer to sssd rather 
than ldap (which is now hopelessly obsoleted).
O.


From: sssd-users-boun...@lists.fedorahosted.org 
[sssd-users-boun...@lists.fedorahosted.org] on behalf of Lukas Slebodnik 
[lsleb...@redhat.com]
Sent: Friday, July 19, 2013 8:54 PM
To: End-user discussions about the System Security Services Daemon
Subject: Re: [SSSD-users] sssd and ldap based sudoers

On (19/07/13 18:25), Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) 
wrote:

I'm working with a customer that has implemented the sudoers schema on
their ldap server and I'd like to know if there are any components that must be 
placed in sssd.conf to get this to work.

The man sudoers.ldap only mentions ldap.conf and not sssd.conf. So to 
enable sudoers on
ldap, do we need both sssd.conf and /etc/ldap.conf ?

If this can all go in sssd.conf, which directives are necessary and what is the 
correct syntax ?

Thanks
Al Licause


I can recommend you to read presentation from "FreeIPA Training Series"
http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf

There is very well explained: How to configure sudo to work with SSSD.
I would not explain it in better.

Regards,
Lukas


___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd and sudo

[Pavel Březina]

On 09/19/2013 06:18 PM, Rowland Penny wrote:

Ok, I am back again, trying to get sssd to control sudo, but failing.

I added the sudo active directory schema ldif to samba4 AD

then added this:

dn: OU=SUDOers,DC=example,DC=com
objectClass: top
objectClass: organizationalUnit
ou: SUDOers

dn: CN=linuxusers,OU=SUDOers,DC=example,DC=com
objectClass: top
objectClass: sudoRole
cn: linuxusers
sudoUser: %linuxusers
sudoHost: ALL
sudoCommand: ALL

On a Linux Mint client:

sudo apt-get install sudo-ldap

Edited /etc/sudo-ldap.conf

# TLS certificates (needed for GnuTLS)
TLS_CACERT  /etc/ssl/certs/ca-certificates.crt
BASE DC=example,DC=com
URI ldap://server.example.com
ssl=no
LDAP_VERSION 3
SUDOERS_BASE ou=SUDOers,DC=example,DC=com
SUDOERS_SEARCH_FILTER (&(objectClass=sudoRole))
BINDDN CN=Administrator,CN=Users,DC=example,DC=com
BINDPW xx

then edited /etc/nsswitch.conf and added

sudoers:   files ldap

restarted sudo

then as a normal user, tried to run a command with sudo, this worked.

I then altered /etc/sssd/sssd.conf and added

services = nss, pam, autofs, sudo

[sudo]

ldap_sudo_search_base = OU=SUDOers,DC=example,DC=com

altered /etc/nsswitch.conf

sudoers:   files sss

restarted sssd
restarted sudo

tried to run the command with sudo again, this time it failed

having been bitten by the way autofs works, I went straight to the way
that sudo & sssd do the ldapsearch:

SUDO
(&(&(objectClass=sudoRole))(|(sudoUser=rowland)(sudoUser=%Domain
Users)(sudoUser=%#20513)(sudoUser=%vboxusers)(sudoUser=%linuxusers)(sudoUser=%#127)(sudoUser=%#21110)(sudoUser=ALL)))


SSSD
(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=ThinkPad)(sudoHost=ThinkPad.home.lan)(sudoHost=192.168.0.204)(sudoHost=192.168.0.0/24)(sudoHost=fe80::86a6:c8ff:fe3b:da7b)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\**)(sudoHost=*[*]*


sudo searches with objectClass=sudoRole & sudoUser attribute
sssd searches with objectClass=sudoRole & sudoHost attribute

Now I understand that the sssd search for the sudoHost attribute is to
ensure that only sudo rules for the host are downloaded, but it doesn't
actually seem to download any rules.

Is there anyway I can get the sssd search to include the sudoUser
attribute in the same way that the sudo ldap search does?


Hi,
no, it is not desirable. SSSD periodically downloads all rules that are 
applicable to the machine, and then filters them by user when sudo 
request is performed. In other words: filtering by sudoUser is there, 
only on other place (sssd_sudo process).


Can you send us (sanitized or privately if you want) your complete 
sssd.conf, sssd_yourdomain.log and sssd_sudo.log please?




Or can anybody tell me where I am going wrong (again).

Rowland


___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd and sudo

[Pavel Březina]

On 09/20/2013 11:09 AM, Rowland Penny wrote:

On 20/09/13 08:36, Pavel Březina wrote:

On 09/19/2013 06:18 PM, Rowland Penny wrote:

Ok, I am back again, trying to get sssd to control sudo, but failing.

I added the sudo active directory schema ldif to samba4 AD

then added this:

dn: OU=SUDOers,DC=example,DC=com
objectClass: top
objectClass: organizationalUnit
ou: SUDOers

dn: CN=linuxusers,OU=SUDOers,DC=example,DC=com
objectClass: top
objectClass: sudoRole
cn: linuxusers
sudoUser: %linuxusers
sudoHost: ALL
sudoCommand: ALL

On a Linux Mint client:

sudo apt-get install sudo-ldap

Edited /etc/sudo-ldap.conf

# TLS certificates (needed for GnuTLS)
TLS_CACERT  /etc/ssl/certs/ca-certificates.crt
BASE DC=example,DC=com
URI ldap://server.example.com
ssl=no
LDAP_VERSION 3
SUDOERS_BASE ou=SUDOers,DC=example,DC=com
SUDOERS_SEARCH_FILTER (&(objectClass=sudoRole))
BINDDN CN=Administrator,CN=Users,DC=example,DC=com
BINDPW xx

then edited /etc/nsswitch.conf and added

sudoers:   files ldap

restarted sudo

then as a normal user, tried to run a command with sudo, this worked.

I then altered /etc/sssd/sssd.conf and added

services = nss, pam, autofs, sudo

[sudo]

ldap_sudo_search_base = OU=SUDOers,DC=example,DC=com

altered /etc/nsswitch.conf

sudoers:   files sss

restarted sssd
restarted sudo

tried to run the command with sudo again, this time it failed

having been bitten by the way autofs works, I went straight to the way
that sudo & sssd do the ldapsearch:

SUDO
(&(&(objectClass=sudoRole))(|(sudoUser=rowland)(sudoUser=%Domain
Users)(sudoUser=%#20513)(sudoUser=%vboxusers)(sudoUser=%linuxusers)(sudoUser=%#127)(sudoUser=%#21110)(sudoUser=ALL)))



SSSD
(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=ThinkPad)(sudoHost=ThinkPad.home.lan)(sudoHost=192.168.0.204)(sudoHost=192.168.0.0/24)(sudoHost=fe80::86a6:c8ff:fe3b:da7b)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\**)(sudoHost=*[*]*



sudo searches with objectClass=sudoRole & sudoUser attribute
sssd searches with objectClass=sudoRole & sudoHost attribute

Now I understand that the sssd search for the sudoHost attribute is to
ensure that only sudo rules for the host are downloaded, but it doesn't
actually seem to download any rules.

Is there anyway I can get the sssd search to include the sudoUser
attribute in the same way that the sudo ldap search does?


Hi,
no, it is not desirable. SSSD periodically downloads all rules that
are applicable to the machine, and then filters them by user when sudo
request is performed. In other words: filtering by sudoUser is there,
only on other place (sssd_sudo process).


Then it would seem to be the later part that is failing

with 'sudoers:files ldap' in /etc/nsswitch.conf

sudo -l
Matching 'Defaults' entries for rowland on this host:
 env_reset, mail_badpass,
secure_path=/usr/local/samba/bin\:/usr/local/samba/sbin\:/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin


User rowland may run the following commands on this host:
 (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py
 (root) ALL

with 'sudoers:files sss' in /etc/nsswitch.conf

sudo -l
Matching 'Defaults' entries for rowland on this host:
 env_reset, mail_badpass,
secure_path=/usr/local/samba/bin\:/usr/local/samba/sbin\:/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin


User rowland may run the following commands on this host:
 (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py


SSSD will not provide any rules for local users or local groups. So even 
if root (local user) is part of linuxusers group (I assume LDAP group) 
than the output is correct.


The rules are provided only for SSSD-managed users and groups.

If you have troubles with LDAP users, I will need those logs.




Can you send us (sanitized or privately if you want) your complete
sssd.conf, sssd_yourdomain.log and sssd_sudo.log please?



No problem, what log level would you like?


0x3ff





Or can anybody tell me where I am going wrong (again).

Rowland



___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd and sudo

[Pavel Březina]

On 09/20/2013 03:40 PM, Rowland Penny wrote:

On 20/09/13 13:49, Pavel Březina wrote:

On 09/20/2013 11:09 AM, Rowland Penny wrote:

On 20/09/13 08:36, Pavel Březina wrote:

On 09/19/2013 06:18 PM, Rowland Penny wrote:

Ok, I am back again, trying to get sssd to control sudo, but failing.

I added the sudo active directory schema ldif to samba4 AD

then added this:

dn: OU=SUDOers,DC=example,DC=com
objectClass: top
objectClass: organizationalUnit
ou: SUDOers

dn: CN=linuxusers,OU=SUDOers,DC=example,DC=com
objectClass: top
objectClass: sudoRole
cn: linuxusers
sudoUser: %linuxusers
sudoHost: ALL
sudoCommand: ALL

On a Linux Mint client:

sudo apt-get install sudo-ldap

Edited /etc/sudo-ldap.conf

# TLS certificates (needed for GnuTLS)
TLS_CACERT  /etc/ssl/certs/ca-certificates.crt
BASE DC=example,DC=com
URI ldap://server.example.com
ssl=no
LDAP_VERSION 3
SUDOERS_BASE ou=SUDOers,DC=example,DC=com
SUDOERS_SEARCH_FILTER (&(objectClass=sudoRole))
BINDDN CN=Administrator,CN=Users,DC=example,DC=com
BINDPW xx

then edited /etc/nsswitch.conf and added

sudoers:   files ldap

restarted sudo

then as a normal user, tried to run a command with sudo, this worked.

I then altered /etc/sssd/sssd.conf and added

services = nss, pam, autofs, sudo

[sudo]

ldap_sudo_search_base = OU=SUDOers,DC=example,DC=com

altered /etc/nsswitch.conf

sudoers:   files sss

restarted sssd
restarted sudo

tried to run the command with sudo again, this time it failed

having been bitten by the way autofs works, I went straight to the way
that sudo & sssd do the ldapsearch:

SUDO
(&(&(objectClass=sudoRole))(|(sudoUser=rowland)(sudoUser=%Domain
Users)(sudoUser=%#20513)(sudoUser=%vboxusers)(sudoUser=%linuxusers)(sudoUser=%#127)(sudoUser=%#21110)(sudoUser=ALL)))




SSSD
(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=ThinkPad)(sudoHost=ThinkPad.home.lan)(sudoHost=192.168.0.204)(sudoHost=192.168.0.0/24)(sudoHost=fe80::86a6:c8ff:fe3b:da7b)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\**)(sudoHost=*[*]*




sudo searches with objectClass=sudoRole & sudoUser attribute
sssd searches with objectClass=sudoRole & sudoHost attribute

Now I understand that the sssd search for the sudoHost attribute is to
ensure that only sudo rules for the host are downloaded, but it
doesn't
actually seem to download any rules.

Is there anyway I can get the sssd search to include the sudoUser
attribute in the same way that the sudo ldap search does?


Hi,
no, it is not desirable. SSSD periodically downloads all rules that
are applicable to the machine, and then filters them by user when sudo
request is performed. In other words: filtering by sudoUser is there,
only on other place (sssd_sudo process).


Then it would seem to be the later part that is failing

with 'sudoers:files ldap' in /etc/nsswitch.conf

sudo -l
Matching 'Defaults' entries for rowland on this host:
 env_reset, mail_badpass,
secure_path=/usr/local/samba/bin\:/usr/local/samba/sbin\:/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin



User rowland may run the following commands on this host:
 (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py
 (root) ALL

with 'sudoers:files sss' in /etc/nsswitch.conf

sudo -l
Matching 'Defaults' entries for rowland on this host:
 env_reset, mail_badpass,
secure_path=/usr/local/samba/bin\:/usr/local/samba/sbin\:/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin



User rowland may run the following commands on this host:
 (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py


SSSD will not provide any rules for local users or local groups. So
even if root (local user) is part of linuxusers group (I assume LDAP
group) than the output is correct.


I am now getting a bit confused, I took the output of 'sudo -l' to mean
'(user_to_runas) what_to_run', so  '(root) ALL' would allow the user to
run all programs as root provided that the correct users password is
entered when prompted.
So as the whole idea is usually for a user to run programs as root and
root is always a local user, you lost me there.


Ah, sorry to confuse you. I messed it up a little. When I saw "root" I 
somehow managed to think that you run "sudo -l" under root user.




The rules are provided only for SSSD-managed users and groups.

I understand this


If you have troubles with LDAP users, I will need those logs.




Can you send us (sanitized or privately if you want) your complete
sssd.conf, sssd_yourdomain.log and sssd_sudo.log please?



No problem, what log level would you like?


0x3ff

Have attached log level 9 logs


Thank for the logs. The LDAP provider stores three rules in the cache. 
Is this correct (sssd stores only those rules that are applicable to the 
machine)?


However, sssd_sudo.log says that sudo didn't comm

Re: [SSSD-users] sssd and sudo

[Pavel Březina]

On 09/21/2013 04:38 PM, Rowland Penny wrote:

On 20/09/13 08:36, Pavel Březina wrote:

On 09/19/2013 06:18 PM, Rowland Penny wrote:

Ok, I am back again, trying to get sssd to control sudo, but failing.

I added the sudo active directory schema ldif to samba4 AD

then added this:

dn: OU=SUDOers,DC=example,DC=com
objectClass: top
objectClass: organizationalUnit
ou: SUDOers

dn: CN=linuxusers,OU=SUDOers,DC=example,DC=com
objectClass: top
objectClass: sudoRole
cn: linuxusers
sudoUser: %linuxusers
sudoHost: ALL
sudoCommand: ALL

On a Linux Mint client:

sudo apt-get install sudo-ldap

Edited /etc/sudo-ldap.conf

# TLS certificates (needed for GnuTLS)
TLS_CACERT  /etc/ssl/certs/ca-certificates.crt
BASE DC=example,DC=com
URI ldap://server.example.com
ssl=no
LDAP_VERSION 3
SUDOERS_BASE ou=SUDOers,DC=example,DC=com
SUDOERS_SEARCH_FILTER (&(objectClass=sudoRole))
BINDDN CN=Administrator,CN=Users,DC=example,DC=com
BINDPW xx

then edited /etc/nsswitch.conf and added

sudoers:   files ldap

restarted sudo

then as a normal user, tried to run a command with sudo, this worked.

I then altered /etc/sssd/sssd.conf and added

services = nss, pam, autofs, sudo

[sudo]

ldap_sudo_search_base = OU=SUDOers,DC=example,DC=com

altered /etc/nsswitch.conf

sudoers:   files sss

restarted sssd
restarted sudo

tried to run the command with sudo again, this time it failed

having been bitten by the way autofs works, I went straight to the way
that sudo & sssd do the ldapsearch:

SUDO
(&(&(objectClass=sudoRole))(|(sudoUser=rowland)(sudoUser=%Domain
Users)(sudoUser=%#20513)(sudoUser=%vboxusers)(sudoUser=%linuxusers)(sudoUser=%#127)(sudoUser=%#21110)(sudoUser=ALL)))



SSSD
(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=ThinkPad)(sudoHost=ThinkPad.home.lan)(sudoHost=192.168.0.204)(sudoHost=192.168.0.0/24)(sudoHost=fe80::86a6:c8ff:fe3b:da7b)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\**)(sudoHost=*[*]*



sudo searches with objectClass=sudoRole & sudoUser attribute
sssd searches with objectClass=sudoRole & sudoHost attribute

Now I understand that the sssd search for the sudoHost attribute is to
ensure that only sudo rules for the host are downloaded, but it doesn't
actually seem to download any rules.

Is there anyway I can get the sssd search to include the sudoUser
attribute in the same way that the sudo ldap search does?


Hi,
no, it is not desirable. SSSD periodically downloads all rules that
are applicable to the machine, and then filters them by user when sudo
request is performed. In other words: filtering by sudoUser is there,
only on other place (sssd_sudo process).

Can you send us (sanitized or privately if you want) your complete
sssd.conf, sssd_yourdomain.log and sssd_sudo.log please?



Or can anybody tell me where I am going wrong (again).

Rowland


___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users


Hi,


OK, I have now got sssd to cache the sudo rules from AD, I found out
that you must have 'defaults' in the AD database, I didn't and thought
you could just use the defaults on the client.


having cn=defaults in LDAP is not necessary. From the logs you've sent 
me, I can see that three rules were stored in the cache.


If the rules are not stored when cn=defaults is missing, it is a bug. 
However, I am unable to reproduce it.



Now, even though sssd has cached the rules, I still cannot get an AD
user to run a command as the root user.

Anybody got any further ideas? or to put it another way, HELP!!


Please, see my earlier response.


Rowland



___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd and sudo

[Pavel Březina]

On 09/23/2013 11:45 AM, Rowland Penny wrote:

On 23/09/13 09:41, Pavel Březina wrote:

On 09/20/2013 03:40 PM, Rowland Penny wrote:

On 20/09/13 13:49, Pavel Březina wrote:

On 09/20/2013 11:09 AM, Rowland Penny wrote:

On 20/09/13 08:36, Pavel Březina wrote:

On 09/19/2013 06:18 PM, Rowland Penny wrote:

Ok, I am back again, trying to get sssd to control sudo, but
failing.

I added the sudo active directory schema ldif to samba4 AD

then added this:

dn: OU=SUDOers,DC=example,DC=com
objectClass: top
objectClass: organizationalUnit
ou: SUDOers

dn: CN=linuxusers,OU=SUDOers,DC=example,DC=com
objectClass: top
objectClass: sudoRole
cn: linuxusers
sudoUser: %linuxusers
sudoHost: ALL
sudoCommand: ALL

On a Linux Mint client:

sudo apt-get install sudo-ldap

Edited /etc/sudo-ldap.conf

# TLS certificates (needed for GnuTLS)
TLS_CACERT  /etc/ssl/certs/ca-certificates.crt
BASE DC=example,DC=com
URI ldap://server.example.com
ssl=no
LDAP_VERSION 3
SUDOERS_BASE ou=SUDOers,DC=example,DC=com
SUDOERS_SEARCH_FILTER (&(objectClass=sudoRole))
BINDDN CN=Administrator,CN=Users,DC=example,DC=com
BINDPW xx

then edited /etc/nsswitch.conf and added

sudoers:   files ldap

restarted sudo

then as a normal user, tried to run a command with sudo, this
worked.

I then altered /etc/sssd/sssd.conf and added

services = nss, pam, autofs, sudo

[sudo]

ldap_sudo_search_base = OU=SUDOers,DC=example,DC=com

altered /etc/nsswitch.conf

sudoers:   files sss

restarted sssd
restarted sudo

tried to run the command with sudo again, this time it failed

having been bitten by the way autofs works, I went straight to
the way
that sudo & sssd do the ldapsearch:

SUDO
(&(&(objectClass=sudoRole))(|(sudoUser=rowland)(sudoUser=%Domain
Users)(sudoUser=%#20513)(sudoUser=%vboxusers)(sudoUser=%linuxusers)(sudoUser=%#127)(sudoUser=%#21110)(sudoUser=ALL)))





SSSD
(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=ThinkPad)(sudoHost=ThinkPad.home.lan)(sudoHost=192.168.0.204)(sudoHost=192.168.0.0/24)(sudoHost=fe80::86a6:c8ff:fe3b:da7b)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\**)(sudoHost=*[*]*





sudo searches with objectClass=sudoRole & sudoUser attribute
sssd searches with objectClass=sudoRole & sudoHost attribute

Now I understand that the sssd search for the sudoHost attribute
is to
ensure that only sudo rules for the host are downloaded, but it
doesn't
actually seem to download any rules.

Is there anyway I can get the sssd search to include the sudoUser
attribute in the same way that the sudo ldap search does?


Hi,
no, it is not desirable. SSSD periodically downloads all rules that
are applicable to the machine, and then filters them by user when
sudo
request is performed. In other words: filtering by sudoUser is there,
only on other place (sssd_sudo process).


Then it would seem to be the later part that is failing

with 'sudoers:files ldap' in /etc/nsswitch.conf

sudo -l
Matching 'Defaults' entries for rowland on this host:
 env_reset, mail_badpass,
secure_path=/usr/local/samba/bin\:/usr/local/samba/sbin\:/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin




User rowland may run the following commands on this host:
 (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py
 (root) ALL

with 'sudoers:files sss' in /etc/nsswitch.conf

sudo -l
Matching 'Defaults' entries for rowland on this host:
 env_reset, mail_badpass,
secure_path=/usr/local/samba/bin\:/usr/local/samba/sbin\:/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin




User rowland may run the following commands on this host:
 (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py


SSSD will not provide any rules for local users or local groups. So
even if root (local user) is part of linuxusers group (I assume LDAP
group) than the output is correct.


I am now getting a bit confused, I took the output of 'sudo -l' to mean
'(user_to_runas) what_to_run', so  '(root) ALL' would allow the user to
run all programs as root provided that the correct users password is
entered when prompted.
So as the whole idea is usually for a user to run programs as root and
root is always a local user, you lost me there.


Ah, sorry to confuse you. I messed it up a little. When I saw "root" I
somehow managed to think that you run "sudo -l" under root user.



The rules are provided only for SSSD-managed users and groups.

I understand this


If you have troubles with LDAP users, I will need those logs.




Can you send us (sanitized or privately if you want) your complete
sssd.conf, sssd_yourdomain.log and sssd_sudo.log please?



No problem, what log level would you like?


0x3ff

Have attached log level 9 logs


Thank for the logs. The LDAP provider stores three rules in the cache.
Is this correct (sssd stores only those rules that are

Re: [SSSD-users] sssd and sudo [SOLVED]

[Pavel Březina]

On 09/23/2013 12:17 PM, Rowland Penny wrote:

On 23/09/13 09:51, Pavel Březina wrote:

On 09/21/2013 04:38 PM, Rowland Penny wrote:

On 20/09/13 08:36, Pavel Březina wrote:

On 09/19/2013 06:18 PM, Rowland Penny wrote:

Ok, I am back again, trying to get sssd to control sudo, but failing.

I added the sudo active directory schema ldif to samba4 AD

then added this:

dn: OU=SUDOers,DC=example,DC=com
objectClass: top
objectClass: organizationalUnit
ou: SUDOers

dn: CN=linuxusers,OU=SUDOers,DC=example,DC=com
objectClass: top
objectClass: sudoRole
cn: linuxusers
sudoUser: %linuxusers
sudoHost: ALL
sudoCommand: ALL

On a Linux Mint client:

sudo apt-get install sudo-ldap

Edited /etc/sudo-ldap.conf

# TLS certificates (needed for GnuTLS)
TLS_CACERT  /etc/ssl/certs/ca-certificates.crt
BASE DC=example,DC=com
URI ldap://server.example.com
ssl=no
LDAP_VERSION 3
SUDOERS_BASE ou=SUDOers,DC=example,DC=com
SUDOERS_SEARCH_FILTER (&(objectClass=sudoRole))
BINDDN CN=Administrator,CN=Users,DC=example,DC=com
BINDPW xx

then edited /etc/nsswitch.conf and added

sudoers:   files ldap

restarted sudo

then as a normal user, tried to run a command with sudo, this worked.

I then altered /etc/sssd/sssd.conf and added

services = nss, pam, autofs, sudo

[sudo]

ldap_sudo_search_base = OU=SUDOers,DC=example,DC=com

altered /etc/nsswitch.conf

sudoers:   files sss

restarted sssd
restarted sudo

tried to run the command with sudo again, this time it failed

having been bitten by the way autofs works, I went straight to the way
that sudo & sssd do the ldapsearch:

SUDO
(&(&(objectClass=sudoRole))(|(sudoUser=rowland)(sudoUser=%Domain
Users)(sudoUser=%#20513)(sudoUser=%vboxusers)(sudoUser=%linuxusers)(sudoUser=%#127)(sudoUser=%#21110)(sudoUser=ALL)))




SSSD
(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=ThinkPad)(sudoHost=ThinkPad.home.lan)(sudoHost=192.168.0.204)(sudoHost=192.168.0.0/24)(sudoHost=fe80::86a6:c8ff:fe3b:da7b)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\**)(sudoHost=*[*]*




sudo searches with objectClass=sudoRole & sudoUser attribute
sssd searches with objectClass=sudoRole & sudoHost attribute

Now I understand that the sssd search for the sudoHost attribute is to
ensure that only sudo rules for the host are downloaded, but it
doesn't
actually seem to download any rules.

Is there anyway I can get the sssd search to include the sudoUser
attribute in the same way that the sudo ldap search does?


Hi,
no, it is not desirable. SSSD periodically downloads all rules that
are applicable to the machine, and then filters them by user when sudo
request is performed. In other words: filtering by sudoUser is there,
only on other place (sssd_sudo process).

Can you send us (sanitized or privately if you want) your complete
sssd.conf, sssd_yourdomain.log and sssd_sudo.log please?



Or can anybody tell me where I am going wrong (again).

Rowland


___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users


Hi,


OK, I have now got sssd to cache the sudo rules from AD, I found out
that you must have 'defaults' in the AD database, I didn't and thought
you could just use the defaults on the client.


having cn=defaults in LDAP is not necessary. From the logs you've sent
me, I can see that three rules were stored in the cache.

If the rules are not stored when cn=defaults is missing, it is a bug.
However, I am unable to reproduce it.


Now, even though sssd has cached the rules, I still cannot get an AD
user to run a command as the root user.

Anybody got any further ideas? or to put it another way, HELP!!


Please, see my earlier response.


Rowland



___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users


Hi, I am fairly sure that I have fixed my problem, it is not a sssd
problem, it is an ubuntu problem.

I was using 'sudo-ldap' as you need this to connect via ldap, so I
assumed I needed it to connect via sssd, this it would seem is wrong.

On: https://launchpad.net/ubuntu/+source/sudo/+changelog

I found this:

1.8.6p3-0ubuntu1
Superseded in raring-release on 2012-12-08
Deleted in raring-proposed on 2012-12-09 (Reason: moved to release)

sudo (1.8.6p3-0ubuntu1) raring; urgency=low

   * New upstream release (1.8.6p3).
   * Add patch to fix building with sssd when ldap is disabled.
   * Drop sudo.manpages and sudo-ldap.manpages as the upstream build system
 now does the right thing here.
   * Build the main sudo package with support for sssd, this doesn't add
any
 additional build time or runtime dependency. sudo will dynamically
load
 the sssd library if 'sss' is listed for the 'sudoers' nss service.
  -- Stephane GraberFri, 16 No

Re: [SSSD-users] [SSSD] New AD provider howto

[Pavel Březina]

On 04/10/2014 04:20 PM, Jakub Hrozek wrote:

Hi,

our current HOWTO[1] on connecting SSSD to an AD DC is outdated,
mostly because the page still only introduces the LDAP provider. Recently, me,
Sumit and Jeremy Agee wrote a new page that specifically advises to use
the AD provider and also use realmd for setup:
https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server

We started a new page and kept the old one around mostly because pre-1.9
versions still need the LDAP provider info.

I'd like to get some review and feedback from our community so we can
link the wiki page from the front page or the documentation section. In
addition to the lists, I also CC-ed the individual contributors to the
original page directly..I hope that's fine.

Thank you for your comments.

[1]
https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20with%20a%20Windows%202008%20Domain%20Server


Hi,
nice article. I have just few nitpicks to sssd.conf.


[sssd]
config_file_version = 2
domains = ad.example.com
services = nss, pam

[domain/ad.example.com]
# Uncomment if you need offline logins
# cache_credentials = true

id_provider = ad
auth_provider = ad
access_provider = ad


I think presenting a minimal configuration would be better, ie removing 
auth and access providers since they are inherited from id.



# Uncomment if service discovery is not working
# ad_server = server.ad.example.com

# Uncomment if you want to use POSIX UIDs and GIDs
# ldap_id_mapping = False


IMHO this description is a little bit misleading. Since you use UIDs and 
GIDs event it id mapping is turned on. It should say "if you have UIDs 
and GIDs set on AD side" or something similar.




# Comment out if the users have the shell and home dir set on the AD side
default_shell = /bin/bash
fallback_homedir = /home/%d/%u

# Uncomment and adjust if the default principal SHORTNAME$@REALM is not 
available
# ldap_sasl_authid = host/client.ad.example@ad.example.com

# Comment out if you prefer to user shortnames.
use_fully_qualified_names = True


___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sudorules - allow all and exclude some

[Pavel Březina]

On 05/07/2014 10:11 AM, Szymon Jazy wrote:

Hello,
Is there a proper way in sudo rules to allow any command and exclude
only some groups?
Something like:
%test_group ALL=(ALL)   ALL, !SU, !SHELLS
If I try to do this (gui/cli) I get an error:
ipa: ERROR: commands cannot be added when command category='all'

Non proper way (bug ?) is to first add deny groups and after that add
allow all :)
It should be fixed in this, but it seems to still work
(freeipa-server-3.3.4-3)
https://fedorahosted.org/freeipa/ticket/1440

Thanks
Szymon


Hi,
this is possible in sudo-ldap (except that you have to specify single 
commands since sudo schema doesn't support command groups), However I am 
not sure whether it is supported by IPA tools. I suggest you to ask on 
freeipa-users list [1].


[1] https://www.redhat.com/mailman/listinfo/freeipa-users

___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd_sudo receives 0 rules but ldap search returns 5, what is wrong?

[Pavel Březina]

On 07/09/2014 10:34 PM, Jakub Hrozek wrote:


On 09 Jul 2014, at 20:00, Rich Megginson  wrote:


re: https://lists.fedorahosted.org/pipermail/sssd-users/2014-July/001891.html


OK, I take back all that I said over on the samba list, sssd does not
pull the sudo rules from AD

I have just spent two hours trying to get sssd to get the sudo rules
from AD on my netbook that I have just installed Linux Mint mate 17 on,
to no effect.

after upping sssd debug to 9, I found this search in sssd_example.com.log:

(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=netbook)(sudoHost=netbook.example.com)(sudoHost=192.168.0.229)(sudoHost=192.168.0.0/24)(sudoHost=fe80::1e4b:d6ff:fec0:e307)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*?*)(sudoHost=*\**)(sudoHost=*[*]*

If I try to search with this via ldbsearch, it does not work, all I get
is this:

allocating request failed: Unable to parse search expression

If I remove one small part, it does work and displays the sudo roles

So, what does this do?

(sudoHost=*\**)


I'm not sure what this search is supposed to do.  What is the intention of this? If it is to search 
for any sudoHost value with a literal asterisk "*" character in it, then the search 
filter syntax is wrong.  According to http://tools.ietf.org/html/rfc4515, if you want to use a 
"*" in a search filter, it must be escaped like this: \2A, so the search filter would be 
(sudoHost=*\2A*)



Thanks for chiming in, Rich.

Pavel, can you inspect the code and file a ticket if we have a bug?


Hi,
the search is supposed to find all rules containing a wildcard in 
sudoHost attribute. Thanks for correcting the filter.


I filed: https://fedorahosted.org/sssd/ticket/2377

In the mean time, if you don't use wildcards you can disable the filter 
with: ldap_sudo_include_regexp = false in domain section of your sssd.conf.






because I can only get the search to work without it

Rowland


___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users




___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Debug levels for SSSD

[Pavel Březina]

On 12/02/2014 10:32 PM, Jakub Hrozek wrote:

On Tue, Dec 02, 2014 at 04:20:17PM -0500, Dmitri Pal wrote:

On 12/02/2014 04:14 PM, Jakub Hrozek wrote:

On Tue, Dec 02, 2014 at 04:00:33PM -0500, Dmitri Pal wrote:

HI,

Do we have any place where we describe what level of output one would get
with each level?

sssd.conf has some info:
 https://jhrozek.fedorapeople.org/sssd/git/man/sssd.conf.5.html


This does not show how bitmap values map levels.
IMO from usability POV levels a simpler though bitmaps are more flexible.
If we want people to stop using 1-10 levels we need to stop recommending
them and start recommending bitmaps.


We tried, but bitmaps are just too hard to use for most users. So we
added this sentence to the man page:


That is one thing, the other thing is that we are still quite 
inconsistent with the bit maps in the old code where numeric levels were 
used. The numbers were converted only on syntax level not the semantic one.


One day, we may want to make the bitmask more refined. For example we 
can move too low level messages (such as sbus_toggle_watch, ldb tevent, 
...) to a separate level because those are not usually needed but other 
"level 9" messages can still be helpful.





SSSD supports two representations for specifying the debug level. The
simplest is to specify a decimal value from 0-9, which represents enabling
that level and all lower-level debug messages.
The more comprehensive option is to specify a hexadecimal
bitmask to enable or disable specific levels (such as if you
wish to suppress a level).



But to do that we need to have at least
a set of predefined ones that can address most common cases. And we need to
document them somewhere.
Ticket?


Feel free to file one. I'm afraid my point of view is narrowed because I
know the code..

TBH in reality I either just use "-d 3" to see failures, "-d 7" to use
most traffic or "-d 10" to see everything including tracing...
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users



___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sudo - multiple domains - same username

[Pavel Březina]

On 07/29/2015 10:07 AM, Cumer Cristiano wrote:

Hello,

I have a setup with two different AD domains a.com and b.com in separate 
forests. Im working with sssd-1.11.7

Everything is fine apart from sudo. When I issue an sudo, sssd performs 
authentications always on domain A even if the user logged in belongs to domain 
B.
How can I tell sssd to perform the searches in the domain of the logged in user?

Cristiano


Hi,
if you want to share names between domains, I'm afraid you need to use 
use_fully_qualified_names set to true. But then it has to be also 
reflected by sudoUser attribute at this moment (we have a ticket to fix 
that).


___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] SSSD seriously broken in RHEL 6.7 again?

[Pavel Březina]

On 08/16/2015 06:22 PM, Jakub Hrozek wrote:



On 13 Aug 2015, at 09:54, Ondrej Valousek  wrote:

Sites won't help here  because of 2 reasons:


Pavel, can you keep this issue in mind when you think about the refactoring of 
the failover system?


Will do.




1. You start up the AD site discovery process sequentially connecting to ALL 
DCs that are registered in SRV. This has to be done this way as you do not know 
yet to which site you belong to.
If the random DC you pick up responds, you're lucky and you can finish the 
discovery process and discover the site you belong to.
If you are unlucky, the DC is unresponsive and you'll end up with AD provider 
offline.

2. Once you discovered the site, there is still the risk that some DCs defined 
for the site will be down or unresponsible - so the scenario above can happen 
as well.

Moreover it seems to me that SSSD is doing the site discovery too often. It 
should be done once SSSD starts up or if we spot the IP address change - there 
is no reason to do it otherwise. Nowadays I see it in logs on a regular basis.

Ondrej


To me, this is really serious problem which renders the service discovery 
feature actually unusable.
Ondrej


I see your point, but wouldn't this be solvable better with sites? ie only 
advertise those DCs that the client can actually use rather than working around 
it on the client side?
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

-

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
https://lists.fedorahosted.org/mailman/listinfo/sssd-users




___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] multi ldap domains setup with conflicting uid/gid ranges.

[Pavel Březina]

On 08/21/2015 05:07 PM, Dmitri Pal wrote:

On 08/21/2015 09:04 AM, Pierre Neyron wrote:

Hi,

I would like to use SSSD to allow authentication on linux machines for
users managed in 2 LDAP bases.

While SSSD is capable of supporting several domains, it seems to only
allow to handle the case where uid/gid are well partitioned between the
bases, with no conflicts (each base having its own uid/gid range).

I'm wondering if there is any plan to add support in SSSD for
renumbering uid and gid in the case of bases which are not well
partitioned ?
Or if anyone already faced the problem and found a nice way to manage
such a use case ?

Thanks,
BR



In general this is a bad practice to have users with overlapping uids/gids
There is a feature in works to allow local uid/gid overrides.
I do nto know if this feature is per domain or global.
If per domain it might help you.


Hi, this feature is going to be part of 1.13.1.



Also not all users might need to be treated as POSIX users. This is also
something being explored.



___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SSSD-users] HOWTO: Troubleshooting SUDO

[Pavel Březina]

Hi,
I just submitted a sudo troubleshooting guide [1]. If you find anything 
missing, please, let me know.


[1] https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SSSD-users][PATCH] make globals in *_opts.h extern

[Pavel Březina]

This solves situation where you want to use those globals on other place 
than in *_common.c.


I also created https://fedorahosted.org/sssd/ticket/2890 so we can avoid 
order-dependency on header files such as sysdb_services.h which I had to 
fix for AD patch.
From 69d4f1c08c43cd319a9c88c132cde2b816aad6e6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pavel=20B=C5=99ezina?= 
Date: Wed, 2 Dec 2015 11:21:52 +0100
Subject: [PATCH 1/4] SYSDB: Add missing include to sysdb_services.h

---
 src/db/sysdb_services.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/db/sysdb_services.h b/src/db/sysdb_services.h
index ae058b0884bb6f817b21327de55902dda8864ec8..c74665546fd90c5295ab09f58f476cb0121c06a1 100644
--- a/src/db/sysdb_services.h
+++ b/src/db/sysdb_services.h
@@ -23,6 +23,8 @@
 #ifndef SYSDB_SERVICES_H_
 #define SYSDB_SERVICES_H_
 
+#include "db/sysdb.h"
+
 #define SYSDB_SVC_CLASS "service"
 #define SYSDB_SVC_CONTAINER "cn=services"
 #define SYSDB_SC "objectclass="SYSDB_SVC_CLASS
-- 
2.1.0

From a7a706aa20e0c1a7ad4cd4496308e80d3cd8b278 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pavel=20B=C5=99ezina?= 
Date: Wed, 2 Dec 2015 11:14:06 +0100
Subject: [PATCH 2/4] IPA: Mark globals in ipa_opts.h as extern

To avoid collisions when we want to work with them elsewhere in the code.
---
 Makefile.am  |   1 +
 src/providers/ipa/{ipa_opts.h => ipa_opts.c} |   5 -
 src/providers/ipa/ipa_opts.h | 313 ++-
 3 files changed, 17 insertions(+), 302 deletions(-)
 copy src/providers/ipa/{ipa_opts.h => ipa_opts.c} (99%)

diff --git a/Makefile.am b/Makefile.am
index 444041f1523986963f49c9e50ae78d0416ee6fda..0427edf45aabce785bb02f3d760216675e69af0a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2937,6 +2937,7 @@ libsss_krb5_la_LDFLAGS = \
 
 libsss_ipa_la_SOURCES = \
 src/providers/ipa/ipa_init.c \
+src/providers/ipa/ipa_opts.c \
 src/providers/ipa/ipa_common.c \
 src/providers/ipa/ipa_config.c \
 src/providers/ipa/ipa_id.c \
diff --git a/src/providers/ipa/ipa_opts.h b/src/providers/ipa/ipa_opts.c
similarity index 99%
copy from src/providers/ipa/ipa_opts.h
copy to src/providers/ipa/ipa_opts.c
index 78949e3ddec95f7f4303eab905bbbf6ec14ed6ae..bc983ec32d63c37b6fdf06d6009df9084f82d4bf 100644
--- a/src/providers/ipa/ipa_opts.h
+++ b/src/providers/ipa/ipa_opts.c
@@ -20,9 +20,6 @@
 along with this program.  If not, see .
 */
 
-#ifndef IPA_OPTS_H_
-#define IPA_OPTS_H_
-
 #include "src/providers/data_provider.h"
 #include "db/sysdb.h"
 #include "db/sysdb_sudo.h"
@@ -338,5 +335,3 @@ struct sdap_attr_map ipa_autofs_entry_map[] = {
 { "ldap_autofs_entry_value", "automountInformation", SYSDB_AUTOFS_ENTRY_VALUE, NULL },
 SDAP_ATTR_MAP_TERMINATOR
 };
-
-#endif /* IPA_OPTS_H_ */
diff --git a/src/providers/ipa/ipa_opts.h b/src/providers/ipa/ipa_opts.h
index 78949e3ddec95f7f4303eab905bbbf6ec14ed6ae..af12e63d80696d8341a963368e7d3a3694f16812 100644
--- a/src/providers/ipa/ipa_opts.h
+++ b/src/providers/ipa/ipa_opts.h
@@ -24,319 +24,38 @@
 #define IPA_OPTS_H_
 
 #include "src/providers/data_provider.h"
-#include "db/sysdb.h"
-#include "db/sysdb_sudo.h"
-#include "db/sysdb_autofs.h"
-#include "db/sysdb_services.h"
-#include "db/sysdb_selinux.h"
 #include "providers/ldap/ldap_common.h"
 
-struct dp_option ipa_basic_opts[] = {
-{ "ipa_domain", DP_OPT_STRING, NULL_STRING, NULL_STRING },
-{ "ipa_server", DP_OPT_STRING, NULL_STRING, NULL_STRING },
-{ "ipa_backup_server", DP_OPT_STRING, NULL_STRING, NULL_STRING },
-{ "ipa_hostname", DP_OPT_STRING, NULL_STRING, NULL_STRING },
-{ "ipa_hbac_search_base", DP_OPT_STRING, NULL_STRING, NULL_STRING},
-{ "ipa_host_search_base", DP_OPT_STRING, NULL_STRING, NULL_STRING },
-{ "ipa_selinux_search_base", DP_OPT_STRING, NULL_STRING, NULL_STRING },
-{ "ipa_subdomains_search_base", DP_OPT_STRING, NULL_STRING, NULL_STRING },
-{ "ipa_master_domain_search_base", DP_OPT_STRING, NULL_STRING, NULL_STRING },
-{ "krb5_realm", DP_OPT_STRING, NULL_STRING, NULL_STRING},
-{ "ipa_hbac_refresh", DP_OPT_NUMBER, { .number = 5 }, NULL_NUMBER },
-{ "ipa_selinux_refresh", DP_OPT_NUMBER, { .number = 5 }, NULL_NUMBER },
-{ "ipa_hbac_support_srchost", DP_OPT_BOOL, BOOL_FALSE, BOOL_FALSE },
-{ "ipa_automount_location", DP_OPT_STRING, { "default" }, NULL_STRING },
-{ "ipa_ranges_search_base", DP_OPT_STRING, NULL_STRING, NULL_STRING },
-{ "ipa_enable_dns_sites", DP_OPT_BOOL, BOOL_FALSE, BOOL_FALSE },
-{ "ipa_server_mode", DP_OPT_BOOL, BOOL_FALSE, BOOL_FALSE },
-{ "ipa_views_search_base", DP_OPT_STRING, NULL_STRING, NULL_STRING },
-{ "krb5_confd_path", DP_OPT_STRING, { KRB5_MAPPING_DIR }, NULL_STRING },
-DP_OPTION_TERMINATOR
-};
+extern struct dp_option ipa_basic_opts[];
 
-struct dp_option ipa_dyndns_opts[] = {
-{ "dyndns_update", DP_OPT_BOOL, BOOL_FALSE, BOOL_FALSE },
-{ "dyndns_refresh_interval", DP_OPT_NUMBER, NULL_NUMBER, NULL_NUM

[SSSD-users]Re: [PATCH] make globals in *_opts.h extern

[Pavel Březina]

On 12/02/2015 11:32 AM, Pavel Březina wrote:

This solves situation where you want to use those globals on other place
than in *_common.c.

I also created https://fedorahosted.org/sssd/ticket/2890 so we can avoid
order-dependency on header files such as sysdb_services.h which I had to
fix for AD patch.


I accidentally sent it to user list, please ignore :-)
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: multiple sudo rules?

[Pavel Březina]

On 02/18/2016 07:37 PM, Mote, Todd wrote:

Hi all, how does sssd process multiple sudo rules from an OU search
base?  I have my base pointed at an OU where I have one sudo rule
applied, and that works, but have another farther down.  I can see in
the logs that it sees both rules. What I can’t find is how sssd handles
that?  does it merge the rules?


If cn is the same I'd rather say that the behaviour is undefined - we 
don't deal with conflicts. If the cn are different that it should be fine.


  How does it handle conflicts?  Does

computer object location matter like it does for group policies?


sudo itself doesn't know about computer objects, it uses just hostnames.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Using sssd sudo with CIDR addressing

[Pavel Březina]

On 04/23/2016 01:33 PM, Michael Ströder wrote:

Kelley Cook wrote:

I've seem to have noticed a problem with using sssd with LDAP SudoHost's that 
contain CIDR addresses.

We break our clusters into subnets and each have a few rules explicitly for 
those systems
Lets call them

cluster_a 192.168.1.0/24
cluster_b 192.168.2.0/24
cluster_c1 192.168.3.0/25
cluster_c2 192.168.3.128/25
cluster_d 192.168.4.0/23
cluster_f 192.168.6.0/24

...
cluster_z: 192.168.26.0/24

Each one may (or may not) have individual sudoUser / sudoCommand allowing 
certain groups access.

So in LDAP for cluster b we have for example
dn: cn=cluster_b,ou=sudoers,dc=EXAMPLE,dc=COM
objectClass: top
objectClass: sudoRole
cn: cluster_root
sudoHost: 192.168.2.0/24
sudoUser: Buser1
sudoUser: Buser2
sudoCommand: su - sap


But then we have few additional sudo rules (mostly for administrators) which 
encompass that whole group of clusters:

dn: cn=cluster_all,ou=sudoers,dc=EXAMPLE,dc=COM
objectClass: top
objectClass: sudoRole
cn: cluster_all
sudoHost: 192.168.0.0/19
sudoUser: Admin1
sudoUser: Admin2
sudoCommand: ALL

This worked fine when just using sudo pointing to our ldap server.  As sudo 
apparently on execution grabs all the rules and figures out if our host is in 
it.  It has been working like this for us for years.

But it is no longer working now that we are attempting to implement sssd 
caching.  Namely because sssd sends an ldap query for sudoHost={ALL, current 
hostname, current IP, and just the currently used subnet (say 192.168.8.0/24) 
}. Not all possible larger sub ranges to which it belongs.

We've worked around it for now by putting in all the various subranges we use, 
but that has made the sudo rules in LDAP really messy and worse always subject 
to change as we add an delete specialized equipment.

Can someone confirm this behavior?


If I understand you correctly you're implementing something like netgroups in
sudoHost CIDR values. In general I'd say: use a decent user management to avoid
the need for that. ;-)

I'd try to set in sssd.conf:


Hi,


ldap_sudo_use_host_filter = false


yes, this option should solve your problem. You can also try 
ldap_sudo_ip to specify what subnets you'd like to fetch, but it 
probably won't scale well with your environment.


Ciao, Michael.

___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: (&(objectClass=sudoRole)(modifyTimestamp>=1)) => fail

[Pavel Březina]

On 04/27/2016 05:46 PM, Michael Ströder wrote:

HI!

I'm currently testing a custom build of sssd 1.13.4 against OpenLDAP
server.

I notice this filter in the log:

(&(objectClass=sudoRole)(modifyTimestamp>=1))

Obviously it's a USN fallback filter since USN attribute is not
available on OpenLDAP.
But the LDAP syntax of assertion value "1" is wrong and therefore no match.

Ciao, Michael.


Hi, we had [1] but that should already be fixed in 1.13.4. Can you send 
me SSSD domain logs and your sssd.conf please?

___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: (&(objectClass=sudoRole)(modifyTimestamp>=1)) => fail

[Pavel Březina]

On 04/28/2016 11:46 AM, Michael Ströder wrote:

On 2016-04-28 11:18, Pavel Březina wrote:

On 04/27/2016 05:46 PM, Michael Ströder wrote:

I'm currently testing a custom build of sssd 1.13.4 against OpenLDAP
server.

I notice this filter in the log:

(&(objectClass=sudoRole)(modifyTimestamp>=1))

Obviously it's a USN fallback filter since USN attribute is not
available on OpenLDAP.
But the LDAP syntax of assertion value "1" is wrong and therefore no
match.


Hi, we had [1] but that should already be fixed in 1.13.4. Can you
send me SSSD domain logs and your sssd.conf please?


I assume with [1] you meant a ticket. Which [1]?

Which log level do you want to see?


Oops, here is link to the ticket:
https://fedorahosted.org/sssd/ticket/2970
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: cache question

[Pavel Březina]

On 04/29/2016 10:30 AM, Ondrej Valousek wrote:

Hi List,

[root@machine ~]# sss_cache -g mpeg2

No cache object matched the specified search

[root@machine ~]# getent -s sss group mpeg2

mpeg2:*:139:

Is this normal behavior? I have deleted mpeg2 group recently…

Only after I do ‘sss_cache –G’ it goes away eventually….

Thanks,

Ondrej


Hi,
so if I understand it correctly the group is still in cache but 
sss_cache won't invalidate it?


What version of sssd do you use? And what can we get from:
sss_cache --debug 0x3ff0 -g mpeg2
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: cache question

[Pavel Březina]

On 04/29/2016 10:42 AM, Ondrej Valousek wrote:

Hi, yes.
This seems to be mostly problem when enumeration is turned on.
Looks like when enumeration is turned off, 'sss_cache -g' does not complain in 
the same scenario (group deleted).
Does it make any sense to submit bug report or enumeration is no longer 
„supported“ feature?


In this case, Jakub may be right that the group may be still present in 
the memory cache (5 minutes is default) even though enumeration has 
already removed the entry. If you can reproduce it, try disabling memory 
cache either with memcache_timeout=0 in [nss] or by creating env 
variable SSS_NSS_USE_MEMCACHE="no".




Ondrej


-Original Message-
From: Pavel Březina [mailto:pbrez...@redhat.com]
Sent: Friday, April 29, 2016 10:36 AM
To: sssd-users@lists.fedorahosted.org
Subject: [SSSD-users] Re: cache question

On 04/29/2016 10:30 AM, Ondrej Valousek wrote:

Hi List,

[root@machine ~]# sss_cache -g mpeg2

No cache object matched the specified search

[root@machine ~]# getent -s sss group mpeg2

mpeg2:*:139:

Is this normal behavior? I have deleted mpeg2 group recently…

Only after I do ‘sss_cache –G’ it goes away eventually….

Thanks,

Ondrej


Hi,
so if I understand it correctly the group is still in cache but sss_cache won't 
invalidate it?

What version of sssd do you use? And what can we get from:
sss_cache --debug 0x3ff0 -g mpeg2
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

-

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
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org


___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: DNS resolver broken in sssd?

[Pavel Březina]

On 08/11/2016 03:58 PM, Jakub Hrozek wrote:

On Thu, Aug 11, 2016 at 12:21:43PM +, Ondrej Valousek wrote:

There is output of the log file (debug 0x1FF):
...
(Wed Aug 10 02:22:24 2016) [sssd[be[default]]] [resolve_srv_done] (0x0400): SRV 
lookup did not return any new server.
(Wed Aug 10 02:22:24 2016) [sssd[be[default]]] [set_srv_data_status] (0x0100): 
Marking SRV lookup of service 'AD' as 'not resolve
d'
(Wed Aug 10 02:22:24 2016) [sssd[be[default]]] [be_resolve_server_process] 
(0x0080): Couldn't resolve server (SRV lookup meta-server), resolver returned 
(1432158231)


Ah, 'good' that you could reproduce this. We already found a similar
(same?) issue some time ago, but were never sure what's going on.
(Sorry, the BZ is private and contains a ton of customer data..)


What BZ do you mean?



Pavel, maybe with Ondrej's help we could figure it out?


(Wed Aug 10 02:22:24 2016) [sssd[be[default]]] [be_resolve_server_process] 
(0x1000): Trying with the next one!
(Wed Aug 10 02:22:24 2016) [sssd[be[default]]] [fo_resolve_service_send] 
(0x0100): Trying to resolve service 'AD'
(Wed Aug 10 02:22:24 2016) [sssd[be[default]]] [get_server_status] (0x1000): 
Status of server 'server1.prague.com' is 'name resolved'
(Wed Aug 10 02:22:24 2016) [sssd[be[default]]] 
[fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds
(Wed Aug 10 02:22:24 2016) [sssd[be[default]]] [resolve_srv_send] (0x0200): The 
status of SRV lookup is not resolved
(Wed Aug 10 02:22:24 2016) [sssd[be[default]]] [fo_set_port_status] (0x0100): 
Marking port 0 of server '(no name)' as 'not working'
(Wed Aug 10 02:22:24 2016) [sssd[be[default]]] [be_resolve_server_process] 
(0x0080): Couldn't resolve server (server1.prague.com), resolver returned (5)
(Wed Aug 10 02:22:24 2016) [sssd[be[default]]] [be_resolve_server_process] 
(0x1000): Trying with the next one!
(Wed Aug 10 02:22:24 2016) [sssd[be[default]]] [fo_resolve_service_send] 
(0x0100): Trying to resolve service 'AD'
(Wed Aug 10 02:22:24 2016) [sssd[be[default]]] [get_server_status] (0x1000): 
Status of server 'server1.prague.com' is 'name resolved'
(Wed Aug 10 02:22:24 2016) [sssd[be[default]]] 
[fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds
(Wed Aug 10 02:22:24 2016) [sssd[be[default]]] [resolve_srv_send] (0x0200): The 
status of SRV lookup is not resolved
(Wed Aug 10 02:22:24 2016) [sssd[be[default]]] [fo_set_port_status] (0x0100): 
Marking port 0 of server '(no name)' as 'not working'
(Wed Aug 10 02:22:24 2016) [sssd[be[default]]] [be_resolve_server_process] 
(0x0080): Couldn't resolve server (server1.prague.com), resolver returned (5)

TCPdump shows (this time) that query has been sent to DNS servers and response 
followed in no time. So there is deffinitely no problem with DNS here.


Does dig or nslookup return valid answer? Can you pm me case number?



Ondrej


-Original Message-
From: Lukas Slebodnik [mailto:lsleb...@redhat.com]
Sent: Thursday, August 11, 2016 10:12 AM
To: End-user discussions about the System Security Services Daemon 

Subject: [SSSD-users] Re: DNS resolver broken in sssd?

On (11/08/16 08:06), Ondrej Valousek wrote:

Hi list,

I am regularly getting messages like:

(Mon Aug  8 21:20:19 2016) [sssd[be[default]]]
[be_resolve_server_process] (0x0080): Couldn't resolve server
(myserver.com), resolver returned (5) Or (Wed Aug 10 15:47:46 2016)
[sssd[be[default]]] [nsupdate_get_addrs_done] (0x0040): Could not
resolve address for this machine, error [5]: Input/output error,
resolver returned: [11]: Could not contact DNS servers


It would be good to see more context from log files (maybe the full debug level 
9)

LS
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

-

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
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: net groups with IPA

[Pavel Březina]

On 11/08/2017 11:47 PM, Charles Hedrick wrote:

In my opinion the whole rfc3704bis implementation of net groups is wonky.

This isn’t the only problem. Why is there a distinction between internal and 
external hosts? Suppose I add an external host to a net group, and later do ipa 
host-add for it. If the distinction actually matters I’d expect the system to 
turn the external host entry into an internal host entry. But it doesn’t.

In principle there’s a difference between blank and -, but the ipa 
implementation always produces - for missing user and host and blank for 
missing domain name.

I’d really rather see the system just store the triples rather than doing a 
complex mapping going in and out.



On Nov 8, 2017, at 5:08 PM, Jakub Hrozek  wrote:

Pavel, does this sound like the bug you were looking at wrt sudo lately?

On Wed, Nov 08, 2017 at 09:46:25PM +, Charles Hedrick wrote:

Netapp wants the domain field to be blank. That leaves us a problem that’s hard 
to solve.

On Nov 8, 2017, at 4:41 PM, Charles Hedrick 
mailto:hedr...@rutgers.edu>> wrote:

OK, I see what’s going on, but it looks like a bug.

We mostly use net groups for hosts. In NIS our entries like like (hostname,,)  
You can put that into IPA by specifying NISdomain=, i.e. blank domain name. 
However if you do that, getent shows no entries. That is, entries with blank 
hostname are ignored. I claim this is a bug, since for a host entry there’s no 
reason to specify a domain.

I also found that specifying

ipa_netgroup_domain=cs.rutgers.edu

causes no net groups to display, even ones whose domain is 
cs.rutgers.edu.
 This also looks like a bug.

On Nov 8, 2017, at 3:53 PM, Charles Hedrick 
mailto:hedr...@rutgers.edu>> wrote:

We want to move our net groups from NIS to IPA. I’ve loaded the groups. They’re 
visible on a system that uses nslcd pointed at the IPA server. But the systems 
that use SSSD for authentication don’t show anything. The net groups all show 
as undefined.

I’ve turned on debugging and looked at the LDAP logs. It does the right quotes 
and the log says it extracts the members. But they don’t show up.

Any idea where to look?


Can you send us some example of what you are trying to achieve and what 
does not work? I'm also ccing Alexander Bokovoy to see why IPA adds 
somewhere dash and somewhere blanks.

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] SSSD Virtual Test Suite

[Pavel Březina]

Hello,

It took me a lot longer than I expected but here it is at last. This is 
my set of scripts that use vagrant and Ansible to automatically 
provision virtual environment that I use to develop and test SSSD.


To create this environment you only need to run one command:
$ ./setup.sh

and after a while you have several machines provisioned and ready. This 
machines include LDAP, IPA and AD servers with one machine dedicated to

SSSD. This machine is already enrolled to those servers.

To start building and/or testing SSSD with all available providers, you 
can just run:

$ vagrant ssh client

Additionally, it allows you to automatically source your set of scripts 
on each login and access IPA web-ui from your browser.


I tried to make the provisioning as fast as possible but it still takes 
approximately one hour on my machine. So be patient.


Any ideas and patches for improvements are welcomed.

The source is available at:
https://github.com/pbrezina/sssd-test-suite
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: [SSSD] Re: SSSD Virtual Test Suite

[Pavel Březina]

On 11/13/2017 05:43 PM, Fabiano Fidêncio wrote:

On Mon, Nov 13, 2017 at 11:16 AM, Pavel Březina  wrote:

Hello,

It took me a lot longer than I expected but here it is at last. This is my
set of scripts that use vagrant and Ansible to automatically provision
virtual environment that I use to develop and test SSSD.

To create this environment you only need to run one command:
$ ./setup.sh

and after a while you have several machines provisioned and ready. This
machines include LDAP, IPA and AD servers with one machine dedicated to
SSSD. This machine is already enrolled to those servers.

To start building and/or testing SSSD with all available providers, you can
just run:
$ vagrant ssh client

Additionally, it allows you to automatically source your set of scripts on
each login and access IPA web-ui from your browser.

I tried to make the provisioning as fast as possible but it still takes
approximately one hour on my machine. So be patient.

Any ideas and patches for improvements are welcomed.


The source is available at:
https://github.com/pbrezina/sssd-test-suite



Okay, I've found some small issues related to the readme and some few
annoyances while trying to run the scripts.

For the former, I'll open some PRs. For the latter, it's worth to
discuss what's your preference/understand better the requirements:

1) Why do have to run the script as root? AFAIU there's some way to
escalate privileges when running an Ansible script (example, running
sudo whenever it's needed). Is that something desired?


Scripts do not require root privileges, Ansible will use sudo when 
needed. But libvirt does, so everytime you run vagrant you have to 
provide root password, unless you change it through policy kit.


Given the fact that the primary use case is for developers I didn't 
spend time on making this configurable and ansible will create a polkit 
rule to always allow access.



2) Restarting NetworkManager is quite intrusive, mainly without any
kind of warning.


Please, send a PR for readme, I'll see if there can be any prompt by 
Ansible.



3) Why do we need Vagrant 2.0 as the minimum version?


Communications with Windows machine require WinRM protocol which, as I 
understood, is not yet handled by older vagrant versions. Vagrant 2 was 
recommended by the windows boxes creator.


Maybe it will work with lower version, I did not test it.


4) The guide was written for Fedora systems ... what's the reason to
choose Fedora over CentOS?


I run Fedora on my machine, did not test it on other systems.


It will take a long time to download all the vagrant images, but I'll
get back here with the feedback as soon as this process is over.


I hope it will work. Each time I though I'm finished, some other problem 
has appeared. But this version got stable on my machine.



Amazing initiative! Thanks a lot, Pavel!


Thank you.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: Passwordless SUDO commands in AD

[Pavel Březina]

On 12/04/2017 09:15 PM, Max DiOrio wrote:

Hi,

We use Active Directory to manage our Linux access including SUDO
permissions.

We need to have a particular account run a passwordless command.  I
created a new sudoRule in AD, added the following:

sudoCommand  /bin/systemctl restart wildfly.service
sudoHost   +DevTestLinuxServer(our group of servers)
sudoOption!authenticate
sudoOrder  1
sudoUsersvc_Jenkins_DTS

From what I'm reading, sudoOrder should be 0 when not defined, which it
isn't in the other sudoRoles.  So with this having a sudoOrder 1, it
should take precedence when there's more than one match for the
command.  The other sudoRole is ALL:ALL, but requires a password, and
that one works fine.

On the client side, logged in as svc_Jenkins_DTS, I see the following in
the sudo log:

(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sort_sudo_rules] (0x0400):
Sorting rules with higher-wins logic
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_fetch_rules] (0x0400):
Returning 2 rules for
[svc_jenkins_...@internal.ieeeglobalspec.com@internal.ieeeglobalspec.com
]
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_build_response]
(0x2000): error: [0]
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_build_response]
(0x2000): rules_num: [0]
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_build_response]
(0x2000): rule [1]/[2]
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): cn:jenkins
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): objectClass:sudoRule
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoCommand:/bin/systemctl restart wildfly.service
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoHost:+DevTestLinuxServer
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoOption:!authenticate
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoOrder:1
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoRunAsUser:ALL
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoUser:#1002202276
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_build_response]
(0x2000): rule [2]/[2]
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): cn:DevTest
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): objectClass:sudoRule
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoCommand:ALL
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoHost:+DevTestLinuxServers
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoRunAsUser:ALL
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoUser:#1002202276


So it knows of both rules, and sorted them properly.

But doing a sudo -l showing the following:

[svc_jenkins_dts@la-1dglsesgap01 ~]$ sudo -l
[sudo] password for svc_jenkins_dts:
Matching Defaults entries for svc_jenkins_dts on la-1dglsesgap01:
!visiblepw, always_set_home, match_group_by_gid, env_reset,
env_keep="COLORS DISPLAY HOSTNAME
HISTSIZE KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME
LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY
LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL
LANGUAGE LINGUAS
_XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User svc_jenkins_dts may run the following commands on la-1dglsesgap01:
(ALL) ALL


So
1) why does it not show in the list it can run the command
2) why does it keep prompting for a password when I try to run the command

Thanks!




Hi Max,
what sssd version do you use? Also, can you send us sudo logs? [1] is a 
guide how to obtain them.


[1] https://pagure.io/SSSD/docs/blob/master/f/users/sudo_troubleshooting.rst


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: SSSD and SUDO not working

[Pavel Březina]

Hi, I quickly read through this thread.

The sudorule that you are using (below) does not have sudoCommand 
attribute specified. If you want to allow all commands, you still must 
set sudoCommand: ALL. If you want to allow only the command from the 
first mail, you must set it as well.


# SystemAdmin, sudoers, MYDOMAIN.COM
dn: cn=SystemAdmin,ou=sudoers,dc=MYDOMAIN,dc=COM
cn: SystemAdmin
sudoRunAsUser: ALL
sudoRunAsGroup: ALL
sudoHost: ALL
sudoUser: %SystemAdmin
sudoOrder: 0
objectClass: sudoRole
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: Passwordless SUDO commands in AD

[Pavel Březina]

On 12/19/2017 11:27 PM, Max DiOrio wrote:

Hey Jakub,

I sent a response almost immediately - which is why I followed up when I
hadn't heard back.  You guys normally respond quickly.

The log files are available here.  I attached them last time - maybe
that was the problem?
https://drive.google.com/open?id=1ht1Hf0RxzoOMQPZUUTUARM3R_tYEEYA_

We're using 1.15.2 of sssd.  Thanks!


I'm sorry for the delay, the reply have not reached us.

I believe you have a typo in the sudoHost attribute of your rule:

netgroup DevTestLinuxServer matches 
(la-1dglsesgap01.internal.ieeeglobalspec.com|la-1dglsesgap01, , ): false 
@ netgr_matches() ./match.c:1139


netgroup DevTestLinuxServers matches 
(la-1dglsesgap01.internal.ieeeglobalspec.com|la-1dglsesgap01, , ): true 
@ netgr_matches() ./match.c:1139


Shouldn't your netgroup name in the failing rule be also in plural -- 
DevTestLinuxServers?




Max



On Tue, Dec 19, 2017 at 5:16 AM, Jakub Hrozek mailto:jhro...@redhat.com>> wrote:

On Mon, Dec 18, 2017 at 11:11:25PM +, Max DiOrio wrote:
> Hey guys? Any thoughts on this? It's impacting our production environment.
>
> Thanks!

I think Pavel's reply must have missed you, I think we still need the
logs he requested:


https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/message/4BMTOMUM4DNDFV3KSWSSPLLKLLM2IX7R/


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org

To unsubscribe send an email to
sssd-users-le...@lists.fedorahosted.org





___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: sss_override user-export is empty

[Pavel Březina]

On 06/24/2018 05:04 AM, vad...@gmail.com wrote:
I made a change in UID for a user with sss_override but user-export to a 
file does not export anything. I am using sssd version 1.15.2. Is this a 
bug or may be I am doing something wrong? I followed the steps from this 
https://jhrozek.wordpress.com/2016/02/15/sssd-local-overrides/


I ran these as root
# sssd --version
1.15.2
# sss_override user-add mwvande -u 4311
# systemctl restart sssd
# sss_override user-export foo
# cat foo
(no output)

I also tried it without the restart

# sss_override user-add mwvande -u 4311
# sss_override user-export foo
# cat foo
(no output)


--
Asif Iqbal


Hi Asif,
does 'getent passwd mwvande' yield overridden uid? Does the following 
command yield anything?


# sss_override user-find
___
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.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/IBUJ2G2VLZIX5GYTEEZO3I3HDJEX4F76/

[SSSD-users] Re: sssd fails to start when I enable [ifp]

[Pavel Březina]

On 10/9/18 11:06 AM, Ondrej Valousek wrote:

Ok I know what is going on.
Sssd-dbus package is necessary accessory for the InfoPipe. So if you need 
InfoPipe, you need to install sssd-dbus (not installed by default).
Fine, but nobody told me that once you install this package, you are also 
expected to restart dbus service.
I guess this needs a bit polishing...


It installs a dbus policy configuration file that is required by dbus. 
D-Bus should be watching the directory for changes though. Please, file 
an sssd ticket for this and we will investigate further.


I think this is a nice task for Tomas (CC)



Ondrej

-Original Message-
From: Ondrej Valousek [mailto:ondrej.valou...@s3group.com]
Sent: Tuesday, October 09, 2018 10:56 AM
To: End-user discussions about the System Security Services Daemon 

Subject: [SSSD-users] Re: sssd fails to start when I enable [ifp]

The same error I receive when I try to start the ifp service manually:
# /usr/libexec/sssd/sssd_ifp --uid 0 --gid 0 --dbus-activated --logger=stderr 
...
(Tue Oct  9 09:53:40 2018) [sssd[ifp]] [parse_attr_list_ex] (0x2000): Added allowed attr sn to whitelist (Tue Oct  9 
09:53:40 2018) [sssd[ifp]] [parse_attr_list_ex] (0x2000): Added default attr name to whitelist (Tue Oct  9 09:53:40 
2018) [sssd[ifp]] [parse_attr_list_ex] (0x2000): Added default attr uidNumber to whitelist (Tue Oct  9 09:53:40 2018) 
[sssd[ifp]] [parse_attr_list_ex] (0x2000): Added default attr gidNumber to whitelist (Tue Oct  9 09:53:40 2018) 
[sssd[ifp]] [parse_attr_list_ex] (0x2000): Added default attr gecos to whitelist (Tue Oct  9 09:53:40 2018) [sssd[ifp]] 
[parse_attr_list_ex] (0x2000): Added default attr homeDirectory to whitelist (Tue Oct  9 09:53:40 2018) [sssd[ifp]] 
[parse_attr_list_ex] (0x2000): Added default attr loginShell to whitelist (Tue Oct  9 09:53:40 2018) [sssd[ifp]] 
[parse_attr_list_ex] (0x2000): Added default attr groups to whitelist (Tue Oct  9 09:53:40 2018) [sssd[ifp]] 
[parse_attr_list_ex] (0x2000): Added default attr domain to whitelist (Tue Oct  9 09:53:40 2018) [sssd[ifp]] 
[parse_attr_list_ex] (0x2000): Added default attr domainname to whitelist (Tue Oct  9 09:53:40 2018) [sssd[ifp]] 
[sysbus_init] (0x0020): Unable to request name on the system bus: [Connection ":1.33561" is not allowed to 
own the service "org.freedesktop.sssd.infopipe" due to security policies in the configuration file] (Tue Oct  
9 09:53:40 2018) [sssd[ifp]] [sysbus_init] (0x0040): DBus error message: Connection ":1.33561" is not allowed 
to own the service "org.freedesktop.sssd.infopipe" due to security policies in the configuration file (Tue 
Oct  9 09:53:40 2018) [sssd[ifp]] [ifp_process_init] (0x0020): Failed to connect to the system message bus (Tue Oct  9 
09:53:40 2018) [sssd[ifp]] [sss_responder_ctx_destructor] (0x0400): Responder is being shut down


-Original Message-
From: Jakub Hrozek [mailto:jhro...@redhat.com]
Sent: Tuesday, October 09, 2018 10:29 AM
To: End-user discussions about the System Security Services Daemon 

Cc: Pavel Březina 
Subject: [SSSD-users] Re: sssd fails to start when I enable [ifp]

Interesting..Pavel, do you have some idea?


On 9 Oct 2018, at 10:27, Ondrej Valousek  wrote:

Ok, obviously this error message does not appear when using SystemD, therefore 
I try to start it as root interactively, i.e.
# /usr/sbin/sssd -i

-Original Message-
From: Ondrej Valousek [mailto:ondrej.valou...@s3group.com]
Sent: Tuesday, October 09, 2018 10:25 AM
To: End-user discussions about the System Security Services Daemon

Subject: [SSSD-users] Re: sssd fails to start when I enable [ifp]

Hi,
As root, i.e. "systemctl start sssd"
Ondrej

-Original Message-
From: Jakub Hrozek [mailto:jhro...@redhat.com]
Sent: Tuesday, October 09, 2018 10:24 AM
To: End-user discussions about the System Security Services Daemon

Subject: [SSSD-users] Re: sssd fails to start when I enable [ifp]

Do you run sssd as root or the unprivileged sssd user?


On 8 Oct 2018, at 15:29, Ondrej Valousek  wrote:

Hi List,
Seems like sssd fails to start when I enable infopipe (i.e. add “ifp” to the 
services list).
Log says:
(Mon Oct  8 14:18:08 2018) [sssd[ifp]] [sysbus_init] (0x0020): Unable
to request name on the system bus: [Connection ":1.33273" is not
allowed to own the service "org.freedesktop.sssd.infopipe" due to
security policies in the configuration file] (Mon Oct  8 14:18:08
2018) [sssd[ifp]] [sysbus_init] (0x0040): DBus error message:
Connection ":1.33273" is not allowed to own the service
"org.freedesktop.sssd.infopipe" due to security policies in the
configuration file (Mon Oct  8 14:18:08 2018) [sssd[ifp]]
[ifp_process_init] (0x0020): Failed to connect to the system message
bus

This is Centos-7, all updates applied, i.e. dbus-1.10.24,
sssd-1.16.0-19.el7

Thanks,
Ondrej
-

The information contained in this e-mail and in any attachments is confidential 
a

[SSSD-users] Re: Any way to convince realm join not to do authselect in RHEL8?

[Pavel Březina]

On 4/28/19 7:04 PM, Spike White wrote:

BTW,

Even if beforehand in authselect I create a custom profile and set 
/etc/authselect/authselect.conf to this custom/profile.


When I run 'realm join', it still invokes:

  * /usr/bin/sh -c /usr/bin/authselect select sssd with-mkhomedir 
--force && /usr/bin/systemctl enable oddjobd.service && 
/usr/bin/systemctl start oddjobd.service


Hi,

AFAIK there is no way to tell realm not to call authselect. But realm is 
usually run only once so you can always call authselect select 
custom/profile after you call realm join.


If this is not enough for some reason, you need to file RFE against realmd.

 
^^


That is, it overwrites my already-set up /etc/authselect/authselect.conf

custom/profile

with this content:

[root@rhel8test01 authselect]# cat authselect.conf
sssd
with-mkhomedir

Spike

On Sun, Apr 28, 2019 at 11:46 AM Spike White > wrote:


All,

Basically here is the realm command we use to join the appropriate
regional AD domain:

realm join -v --automatic-id-mapping=no
--computer-ou="OU=Servers,OU=UNIX,DC=$SUPPORTREGION,DC=COMPANY,DC=COM" 
--user-principal="host/`hostname --fqdn`@$JOINDOMAIN"  $JOINDOMAIN


As part of this, realm join internally runs the following command:

  * /usr/bin/sh -c /usr/bin/authselect select sssd with-mkhomedir
--force && /usr/bin/systemctl enable oddjobd.service &&
/usr/bin/systemctl start oddjobd.service

But that sets /etc/pam.d/password-auth and /etc/pam.d/system-auth to
a sub-optimal PAM stack.  I.e., not what we desire.

For example,  99.9% of our users are in AD.  So we want to run
pam_sssd *before* pam_unix.

We are very comfortable with testing and debugging PAM stacks.   We
have a stable, tested PAM stack that works great -- ever since RHEL7.

Basically, after the 'realm join' above is done, we have to
overwrite /etc/pam.d/{system-auth,password-auth,postlogin} with what
we desire.

If 'realm join' can't be convinced to not run authselect, we're ok
with creating a custom/profile authselect profile with what we
want.  And then convince realm join to run:

authselect select custom/profile

Instead of the above authselect select sssd

Prior to running 'realm join', I have to drop down a
/etc/realmd.conf file so that the 'realm join' behaves as I want it
to.    Is there any option in realmd.conf to not run authselect or
tailor the authselect command?  Or may a flag on the 'realm
discover' command line?

I don't remember any of these problems with realm join on RHEL7. 
Maybe it was running authconfig inappropriately as well -- and I

just never noticed, because I over-wrote with desired PAM stack?

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: sssd backend not workin on ubuntu 18.04

[Pavel Březina]

On 8/13/19 6:00 PM, Charles Hedrick wrote:

On our Ubuntu 18.04 servers, sssd won’t start. Logging shows that it can’t find 
any DNS servers. Restarting sssd fixes it.

/etc/resolv.conf is a symlink to ../run/systemd/resolve/stub-resolv.conf

If I replace that with a hardcoded resolv.conf with the right name server, sssd 
comes up. Network Manager replaces the file with a different one pointing to 
nameserver 127.0.0.53, but after another reboot with that file it still works.

This happens on 4 identical servers, but not on a VM with the same OS. I assume 
there’s a timing issue of some sort.


I think this PR might help here: https://github.com/SSSD/sssd/pull/864

SSSD did not watch resolv.conf symlinks for changes so if the original 
file did not contains correct DNS server SSSD wouldn't be able to pick 
up the new one after resolv.conf is updated.

___
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: Double-check that I have this sssd.conf right....

[Pavel Březina]

On 10/11/19 6:28 PM, Spike White wrote:
Without domain_resolution_order set, it does not search the non-local 
domain and find any non-local accounts.  (This is on RHEL7 and RHEL8).


So -- domain_resolution_order is required.


Can you send us sssd_nss.log and sssd_$domain.log logs generated with 
debug_level = 0x3ff0? Ideally for both cases - when the option is set 
and when it is not.


I suspected ldap_search_base would be auto-discovered.  However, I got 
lost when parsing the default setting of ldap_search_base in the 
sssd.conf man page:


            Default: If not set, the value of the defaultNamingContext 
or namingContexts attribute from the RootDSE of the LDAP


server is used. If defaultNamingContext does not exist or has an empty 
value namingContexts is used. The


namingContexts attribute must have a single value with the DN of the 
search base of the LDAP server to make this work.


Multiple values are are not supported.


Spike

PS Thanks for responding.


On Wed, Oct 9, 2019 at 11:47 AM Sumit Bose > wrote:


On Mon, Oct 07, 2019 at 09:53:35AM -0500, Spike White wrote:
 > All,
 >
 > I worked an sssd configuration case with my OS vendor in the last
3 weeks.
 > I have resolution and it's working 100% correctly.
 >
 > Just wanted to double-check.  A second set of eyes to verify this
solution
 > is all above board.
 >
 > The problem manifested itself in our multi-domain AD forest with
Posix
 > Attributes.  One parent domain that has a transitive trust with 4
 > (regional) child domains.
 >
 > Thus all 4 child domains trust each other.  All users and groups
are stored
 > in the 4 child domains.
 >
 > The original problem was that I was disabling subdomains_provider and
 > explicitly defining each of the 4 child domains. I had:
 >
 >    domains = amer.company.com
,apac.company.com
, 
 >    ...
 >    [domain/amer.company.com ]
 >    
 >    [domain/apac.company.com ]
 >    ...
 >
 > That worked great -- for everything except universal groups. 
Universal

 > groups exist in the first domain in which they're created, but
they're
 > replicated to each domain.  However, each child domain for this
group's
 > membership only has the local users of that domain.  The full
universal
 > group membership is stored only in the global catalog (GC).
 >
 > The problem?  The GC lookups are done in the subdomain_provider's
code.  So
 > by disabling subdomains_provider, I was disabling GC lookups. 
Thus,  I was

 > getting the group membership only of the first child domain queried (
 > amer.company.com ).
 >
 > What that amounted to is that remote support personnel couldn't
log into
 > local boxes, because they weren't listed in the allowed groups.
 >
 > So I re-wrote the sssd.conf file and only explicitly defined the
one local
 > child domain.  I left on subdomain_provider, so it
auto-discovered the
 > other domains (sssctl domain-list confirms this).
 >
 > Like this:
 >
 >    domains = amer.company.com 
 >    ...
 >    [domain/amer.company.com ]
 >    ldap_search_base = dc=AMER,dc=COMPANY,dc=COM
 >
 >    [domain/amer.company.com/apac.company.com
]
 >    ldap_search_base = dc=APAC,dc=COMPANY,dc=COM
 >
 > So then, universal groups showed all memberships.  The only remaining
 > problem was that now it was only searching the amer.company.com
 child
 > domain.  So while a remote user was listed as a member of an allowed
 > universal group, the details of that user's account was not known.
 >
 > I couldn't add these auto-discovered domains to the "domains"
line.  (only
 > domains explicitly defined in sssd.conf file are allowed in this line
 > apparently).  But I was able to add:
 >
 >    domain_resolution_order = amer.company.com
, emea.company.com ,
 > apac.company.com , japn.company.com
, company.com 
 >
 > Now all works 100%.
 >
 > Is this all legit?  Do you see any problems with above final
sssd.conf
 > setting?

Hi,

the changes are ok. However in theory both are not needed. The
ldap_search_base should be discovered automatically and
domain_resolution_order is only needed if you want SSSD to search the
different domains in exactly that order, without SSSD should still
search all domains until a matching user or group is found, but the
or

[SSSD-users] Re: Is there an RFC or detailed design document describing SSSD's ID Mapping algorithm?

[Pavel Březina]

On 10/17/19 12:17 AM, Jeff Thornsen wrote:

The reason I ask is because I use a bunch of storage appliances that offer 
Secure-NFS (NETAPP, EMC UNITY, etc.), but they only support NIS, IDMU, RFC2307, 
and RFC2307bis style Identity Mapping, all of which require manual assignment 
of UID/GID numbers to objects in LDAP, which is untenable for large 
environments.  Microsoft even removed Unix Attribute editor from their LDAP GUI 
for the RFC2307 attributes in Windows Server 2016 to push people away from 
using rfc2307.

I would like to be able to provide a link to an RFC or design document 
describing the SSSD ID Mapping algorithm so that these 3rd party vendors can 
incorporate an identical identity mapping algorithm into their products, so 
that I can use their Secure-NFS product in conjunction with sssd and have the 
uid and gid numbers match up with the other Linux hosts in our environment.


There is [1]. But I am not sure if it is as thorough as you need and it 
might be also a little outdated. So the best documentation would be the 
sources of sss_idmap library [2]. Also it should be possible to use this 
library instead of implementing your own algorithm.


[1] 
https://docs.pagure.org/SSSD.sssd/design_pages/idmap_auto_assign_new_slices.html

[2] https://github.com/SSSD/sssd/tree/master/src/lib/idmap
___
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: Double-check that I have this sssd.conf right....

[Pavel Březina]

On 10/24/19 6:32 AM, Spike White wrote:

sssd experts,

I think this is proper and expected sssd behavior.    Since I'm using 
short names for all lookups, that is called a "domain-less search".


Yes, if you are using short names the domain_resolution_order is required.



Look at https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html, 
where the implementation of  the "shortnames in trusted domains" feature 
is discussed.


The author explicitly says:


Overview of the

solution<https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html#overview-of-the-solution>

In order to have it implemented a few internal changes have to be done 
in order to use the shared |cache_req| module for responder look-ups, 
allowing then SSSD to perform the domain-less look-ups when not 
explicitly set up in the domain to use only fully-qualified names for 
those operations.


Once domain-less searches are allowed, SSSD will have to support 
receiving an ordered list of domains which will be looked-up first so 
the Administrator can have a better control and avoid a bunch of 
unnecessary look-ups. The list of the ordered domains can be provided in 
three different ways and those are described below according to their 
precedence order:


  * sssd.conf: the admin can set up the |domain_resolution_order| option
in the |[sssd]| section;
  * |ipaDomainResolutionOrder| set by IPA ID-view: the admin can set up
the attribute per views on IPA server;
  * |ipaDomainResolutionOrder| set globally: the admin can set up the
attribute globally on IPA server;


Without setting the list of ordered domains (via any of those 3 methods 
above), I'm thinking that SSSD should do domain-less searches in the 
local domain only.   Which is exactly what happens.


Spike

On Fri, Oct 18, 2019 at 1:23 PM Spike White <mailto:spikewhit...@gmail.com>> wrote:


Pavel and sssd mailing list team members,

OK -- I have reproduced this behaviour as requested.  I set 
debug_level = 0x3ff0? for both cases - when the option is set and

when it is not.

I have done this for both a RHEL7 server and a RHEL8 server.  (Same
behavior on both OS versions.)

Here is the dropbox URL with the tarballs of the logs:

https://www.dropbox.com/sh/yqb4poh9ny9hypg/AAA71mXPDFvZcIThXKofOmVRa?dl=0

That dropbox URL contains two tarballs.

RHEL7_good_and_bad.tgz
RHEL8_good_and_bad.tgz

In each tarball, there's a "good" folder (with
domain_resolution_order set in sssd.conf file) and a "bad" folder
(without domain_resolution_order set in sssd.conf file).

Spike


On Wed, Oct 16, 2019 at 2:57 AM Pavel Březina mailto:pbrez...@redhat.com>> wrote:

On 10/11/19 6:28 PM, Spike White wrote:
 > Without domain_resolution_order set, it does not search the
non-local
 > domain and find any non-local accounts.  (This is on RHEL7
and RHEL8).
 >
 > So -- domain_resolution_order is required.

Can you send us sssd_nss.log and sssd_$domain.log logs generated
with
debug_level = 0x3ff0? Ideally for both cases - when the option
is set
and when it is not.

 > I suspected ldap_search_base would be auto-discovered. 
However, I got

 > lost when parsing the default setting of ldap_search_base in the
 > sssd.conf man page:
 >
 >             Default: If not set, the value of the
defaultNamingContext
 > or namingContexts attribute from the RootDSE of the LDAP
 >
 > server is used. If defaultNamingContext does not exist or has
an empty
 > value namingContexts is used. The
 >
 > namingContexts attribute must have a single value with the DN
of the
 > search base of the LDAP server to make this work.
 >
 > Multiple values are are not supported.
 >
 >
 > Spike
 >
 > PS Thanks for responding.
 >
 >
 > On Wed, Oct 9, 2019 at 11:47 AM Sumit Bose mailto:sb...@redhat.com>
 > <mailto:sb...@redhat.com <mailto:sb...@redhat.com>>> wrote:
 >
 >     On Mon, Oct 07, 2019 at 09:53:35AM -0500, Spike White wrote:
 >      > All,
 >      >
 >      > I worked an sssd configuration case with my OS vendor
in the last
 >     3 weeks.
 >      > I have resolution and it's working 100% correctly.
 >      >
 >      > Just wanted to double-check.  A second set of eyes to
verify this
 >     solution
 >      > is all above board.
 >      >
 >      > The problem manifested itself 

[SSSD-users] Re: Ability to auth sudo against a different back end using sssd.

[Pavel Březina]

On 10/23/19 11:31 PM, Erinn Looney-Triggs wrote:
Folks I am in the process of working through this but I thought I would 
throw it out just in case there were other thoughts or I was chasing 
down the wrong lane.


We have a requirement for sudo to use a different password than the user 
password where I work. Now in RHEL 7 we implemented this requirement by 
modifying the pam stack for sudo to use the pam_krb5 module like the 
following:


auth required pam_env.so
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_krb5.so try_first_pass no_user_check
auth required pam_deny.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_krb5.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_krb5.so try_first_pass use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so

Now pam_krb5 is configured to auth against a username/sudo principal in 
/etc/krb5.conf like the following (the mappings is the important part):


[appdefaults]
  pam = {
    debug = false
    forwardable = true
    renew_lifetime = 24h
    ticket_lifetime = 24h
    krb4_convert = false
    mappings = ^(.*)$ $1/sudo
  }

pam_krb5 has for better or worse gone the way of the dodo in RHEL 8 and 
so I am looking to implement something similar using sssd. Our systems 
are already joined to an AD, and it appears to me for the moment that 
the 'application domain' using pam_sss might be the right approach here. 
I understand that it is best tested with LDAP, but well, here we go. So 
thus far I have:


[application/appdom]
inherit_from = ad.example.com

and the /etc/pam.d/sudo has the following inserted:

auth    sufficient pam_sss.so forward_pass domains=appdom

Great it seems to work. Now I need to remap the name to username/sudo 
and auth it against kerb. I don't even know if this is possible at this 
point, but again I thought I would write it up and ask just in case 
someone knew.


No, this is AFAIK not possible at the moment, as you already found out.

Sumit, given the mapping only appends /sudo to the username, would it 
make sense to open an RFE to support such thing?




Thanks,

-Erinn
___
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: Samba4, sssd on same machine

[Pavel Březina]

On 10/25/19 7:04 PM, Thomas Schweikle wrote:

Hi!

I've set up samba4 as ad-dc -- worked right away.
Exported the keytab. "klist -ke" looks good:
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
 
--
    1 administra...@ada.de  
(aes256-cts-hmac-sha1-96)
    1 administra...@ada.de  
(aes128-cts-hmac-sha1-96)

    1 administra...@ada.de  (arcfour-hmac)
    1 administra...@ada.de  (etype 3)
    1 administra...@ada.de  (etype 1)
    1 krb...@ada.de  (aes256-cts-hmac-sha1-96)
    1 krb...@ada.de  (aes128-cts-hmac-sha1-96)
    1 krb...@ada.de  (arcfour-hmac)
    1 krb...@ada.de  (etype 3)
    1 krb...@ada.de  (etype 1)
    1 AD01$@ADA.DE  (aes256-cts-hmac-sha1-96)
    1 AD01$@ADA.DE  (aes128-cts-hmac-sha1-96)
    1 AD01$@ADA.DE  (arcfour-hmac)
    1 AD01$@ADA.DE  (etype 3)
    1 AD01$@ADA.DE  (etype 1)

checked kinit with the servers name:
# kinit -k AD01\$@ADA.DE 
# klist
Ticketzwischenspeicher: FILE:/tmp/krb5cc_0
Standard-Principal: AD01$@ADA.DE 

Valid starting       Expires              Service principal
25.10.2019 19:00:20  26.10.2019 05:00:20  krbtgt/ada...@ada.de 


         erneuern bis 01.11.2019 18:00:20

looks good too.
Then configured sssd:
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam, pac
domains = ADA.DE 
#debug_level = 0x0270

[domain/ADA.DE ]
enumerate = true
cache_credentials = true

id_provider = ad
auth_provider = ad
sudo_provider = none
chpass_provider = ad
access_provider = ad

ad_server = ad01.ada.de , ad02.ada.de 


ad_maximum_machine_account_password_age = 30
ldap_id_mapping = false
use_fully_qualified_names = false
fallback_homedir = /home/%d/%u
fallback_shell = /bin/bash
skel_dir = /etc/skel

ldap_schema = ad

dyndns_update = false
dyndns_refresh_interval = 43200
dyndns_update_ptr = false
dyndns_ttl = 3600

debug_level = 0x0270

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
#debug_level = 0x0270

[pam]
reconnection_retries = 3
#debug_level = 0x0270

[pac]
reconnection_retries = 3
#debug_level = 0x0270

Then tried:
# getent passwd administra...@ada.de 
#

and got nothing.
Any idea anyone?

--
Thomas


Hi Thomas,
please set debug_level = 0x3ff0 in all sections and send us logs in 
/var/log/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://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: how to say name of daemon? "S-S-S-D" or "TRIPLE-S-D"?

[Pavel Březina]

We, developers, always use S-S-S-D. I have never heard anyone saying 
Triple-S-D :-)


On 11/15/19 1:49 PM, Jim Burwell wrote:

I use both.  Triple-S-D is easier.


On 2019-11-14 19:20, Spike White wrote:

All,

S-S-S-D does not seem to roll off the tongue.  When I say that, 
co-workers think I'm discussing solid-state drives (SSD).  When I call 
it triple-S-D, someone invariably corrects me.


Which is correct?  Are both pronunciations correct?

Spike

___
sssd-users mailing list --sssd-users@lists.fedorahosted.org
To unsubscribe send an email tosssd-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 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: Can SSSD sort the autofs map

[Pavel Březina]

On 11/30/19 5:41 PM, Oguzhan Eris wrote:

Hi everyone.

First off, thanks to everyone who's ever worked on SSSD.  It's easily in my top 
5 favorite FOSS projects out there.

I am not sure if this is the right way to ask for an enhancement, or whether I 
should file an issue on GitHub,  but I am running into an issue that's 
described in this Red Hat page   https://access.redhat.com/solutions/3673501 
(login required)

Basically for an automount map where I need nested top level paths:

/mnt/foo
/mnt/foo/bar

each defined by their own map objects.  SSSD does not handle this (neither does 
LDAP directly from autofs) because the return map from LDAP is unsorted, and if 
the maps are provided to autofs ordered as:

/mnt/foo/bar
/mnt/foo

the /mnt/foo map masks the previous /mnt/foo/bar map  and you'll only get the 
entries from /mnt/foo

Using file based mount maps, one can easily sort the top level maps, and get 
around this issue.
Would it be possible to have SSSD return the maps from LDAP query in a sorted 
way?   There is an LDAP control that most LDAP servers support to return a 
sorted output, (
https://ldapwiki.com/wiki/Server%20Side%20Sort%20Control ) but with so many 
clients and a large list, this might be better left to the client to do instead.

I'm happy to help out if someone can point me in the right direction in the 
code.


SSSD is just a data provider, if some sorting is needed I do not think 
it should be done in SSSD (unless autofs interface says so) but rather 
in autofs itself.


CCing Ian, do you have any thoughts on this?



Thanks again
___
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: restrict sudo su -

[Pavel Březina]

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
___
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: restrict sudo su -

[Pavel Březina]

On 1/17/20 1:24 PM, Jakub Hrozek wrote:

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..


I'm not sure what do you mean.


___
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: Proper support for Hostbased Authentication

[Pavel Březina]

On 2/12/20 9:23 PM, Vinícius Ferrão wrote:

Hello,

4 months ago I’ve opened an RFE on pagure about proper support for SSH 
HBA with SSSD fetching hostkeys from LDAP, it’s described here: 
https://pagure.io/SSSD/sssd/issue/4106


Since there’s no updates on the RFE I would like to bring the discussion 
to the list.


I came across another issue regarding SSH HBA on RHEL7, that’s reported 
here: https://bugzilla.redhat.com/show_bug.cgi?id=1801459 and this 
motivated me to bring the discussion to here.


At this moment I’m working around the issue sharing the same SSH Host 
Keys between all the servers that should use SSH Hostbased 
Authentication, which is extremely bad and I really don’t want to 
continue in this path.


So is anyone out there having the same issues with Hostbased 
Authentication with SSSD + IPA?


Thanks,


Hi Vinicius,
I brought some attention to this ticket, see comments there.
___
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: auto-discovering sssd domains in upper case? (one small nit)...

[Pavel Březina]

On 2/22/20 4:52 PM, Spike White wrote:

All,

When I was first crafting my sssd.conf file, I very much attempted to 
make all my sssd domains upper-case.  Because in my (naive) view, an AD 
domain is just a Kerberos realm (+ LDAP + nice admin screens).


As you know, Kerberos is very much case-sensitive.  (Technically, AD is 
not.  but the convention in the /etc/krb5.conf file is to always put 
Kerberos realms in upper case).


Back to sssd.

When sssd auto-discovered the other parent and child domains, it 
discovered them in lower case.  I was left with a mix of upper and 
lower-case sssd domains.  Even worse, the one local AD domain showed up 
twice.  Once in upper-case (explicitly defined in sssd.conf) and once in 
lower-case (auto-discovered).


Eventually, I gave up and went with the (apparently recommended sssd) 
convention of lower-case sssd domain names.  In the domain definition, I 
list the krb5_realm in upper case:


    [domain/amer.example.com ]
    ...
    krb5_realm = AMER.EXAMPLE.COM 

This is extremely unimportant (lower case works).  But is there an 
option to auto-discover sssd domains in upper case?


Lukas summarized the case sensitivity and difference between sssd domain 
and realm pretty good so just to answer your question - no, we currently 
do not have any option to set auto-discovered domain name format.




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: Some more concerning messages

[Pavel Březina]

On 2/25/20 7:56 PM, Orion Poplawski wrote:

Adding trigger line I think.

On 2/25/20 10:59 AM, Orion Poplawski wrote:

On a new EL8 IPA server:

(Sun Feb 23 23:09:29 2020) [sssd[be[nwra.com]]] [dp_get_account_info_send]

(0x0200): Got request for [0x5][BE_REQ_SERVICES][name=ssh]

(Tue Feb 25 10:51:49 2020) [sssd[be[nwra.com]]]
[ipa_get_ad_override_connect_done] (0x0040): dp_id_data_to_override_filter 
failed.
(Tue Feb 25 10:51:49 2020) [sssd[be[nwra.com]]]
[ipa_subdomain_account_got_override] (0x0040): IPA override lookup failed:
1432158283

(Tue Feb 25 10:51:49 2020) [sssd[nss]] [cache_req_common_process_dp_reply]
(0x0040): CR #285589: Data Provider Error: 3, 1432158283, The internal name
format cannot be parsed


sssd-2.2.0-19.el8.x86_64
ipa-server-4.8.0-13.module+el8.1.0+4923+c6efe041.x86_64


Hi, can you please send me complete log? Privately if you wish.
___
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: Some more concerning messages

[Pavel Březina]

On 2/26/20 11:59 AM, Pavel Březina wrote:

On 2/25/20 7:56 PM, Orion Poplawski wrote:

Adding trigger line I think.

On 2/25/20 10:59 AM, Orion Poplawski wrote:

On a new EL8 IPA server:

(Sun Feb 23 23:09:29 2020) [sssd[be[nwra.com]]] 
[dp_get_account_info_send]

(0x0200): Got request for [0x5][BE_REQ_SERVICES][name=ssh]

(Tue Feb 25 10:51:49 2020) [sssd[be[nwra.com]]]
[ipa_get_ad_override_connect_done] (0x0040): 
dp_id_data_to_override_filter failed.

(Tue Feb 25 10:51:49 2020) [sssd[be[nwra.com]]]
[ipa_subdomain_account_got_override] (0x0040): IPA override lookup 
failed:

1432158283

(Tue Feb 25 10:51:49 2020) [sssd[nss]] 
[cache_req_common_process_dp_reply]
(0x0040): CR #285589: Data Provider Error: 3, 1432158283, The 
internal name

format cannot be parsed


sssd-2.2.0-19.el8.x86_64
ipa-server-4.8.0-13.module+el8.1.0+4923+c6efe041.x86_64


Hi, can you please send me complete log? Privately if you wish.


Thank you for the logs.

I think this is a bug, can you open a ticket for it?

You do not have to worry about it unless you are defining services in 
LDAP. You can workaround it by setting 'services: files sss' (though 
only if you don't have services managed in LDAP) in /etc/nsswitch.conf, 
that should get rid of the 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://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: ldb_modify/sdap_save_group errors

[Pavel Březina]

On 2/18/20 6:30 PM, Orion Poplawski wrote:

I'm getting lots of messages like the following in our newer EL8 IPA servers:

(Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr]
(0x0080): ldb_modify failed: [No such object](32)[ldb_wait from ldb_modify
with LDB_WAIT_ALL: No such object (32)]
(Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sysdb_set_entry_attr]
(0x0080): Cannot set attrs for name=Wireless
acc...@ad.nwra.com,cn=groups,cn=ad.nwra.com,cn=sysdb, 2 [No such file or
directory]
(Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sysdb_store_group] (0x0040):
Cache update failed: 2
(Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sdap_store_group_with_gid]
(0x0040): Could not store group Wireless acc...@ad.nwra.com
(Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sdap_save_group] (0x0080):
Could not store group with GID: [No such file or directory]
(Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sdap_save_group] (0x0080):
Failed to save group [Wireless acc...@ad.nwra.com]: [No such file or directory]
(Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sdap_save_groups] (0x0040):
Failed to store group 1. Ignoring.

ad.nwra.com is a trusted AD domain.  Is this problematic?

Thanks.


Can you send me complete logs please?
___
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: Can I map an LDAP value of 123456 to a user name of u123456 ?

[Pavel Březina]

On 3/10/20 5:11 AM, Michael Lake wrote:

Hi all

I am currently authenticating users with Centos 6 and sssd to an LDAP
server. I'll be moving to a Centos 8 so have setup sssd to authenticate
to the LDAP server on my test Centos 8 box. However, our users in our
LDAP only contains all numeric identifiers for users. Centos 8 no longer 
accepts all numeric user names and group names


Currently my sssd.conf contains:

ldap_user_uid_number = uid
ldap_user_gid_number = uid
override_homedir = /homes/%u

Our LDAP server contains "uid" values for users like "123456"

I'll still be able to use the LDAP "uid" for UNIX uid and gid but what
I would like to be able to do is have the user name (and group name)
created by prefixing the LDAP "uid" values with a literal "u" to make
them POSIX compliant.

Hence a user 123456 with "uid" of 123456 in LDAP can login and end up
with a username of "u123456".
I can't see a way to do that with a simple template in the "man
ssd.conf"


How about using fully qualified names instead?
___
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: Can I map an LDAP value of 123456 to a user name of u123456 ?

[Pavel Březina]

On 3/10/20 1:53 PM, Michael Lake wrote:

Pavel suggested:
 > How about using fully qualified names instead?

I'm not very familiar with LDAP. I'm not sure what that would actually 
look like.


What we have now is where users login to a terminal using their number. 
However with web based logins they do use their email address.


I'd have to check tomorrow in the LDAP and check what a fully qualified 
name actually is.


Fully qualified name is a name in the form of user@domain. I.e. if you 
have [domain/mydomain] in /etc/sssd/sssd.conf the fully qualified name 
will be number@mydomain.


If they are used to login with their email address, you could also 
switch name attribute to the email address attribute if it is in LDAP.


See ldap_user_name in `man sssd-ldap` and use_fully_qualified_names and 
full_name_format in `man sssd.conf`.



Mike

____
From: Pavel Březina 
Sent: Tuesday, March 10, 2020 11:33 PM
To: End-user discussions about the System Security Services Daemon; 
Michael Lake
Subject: Re: [SSSD-users] Can I map an LDAP value of 123456 to a user 
name of u123456 ?


On 3/10/20 5:11 AM, Michael Lake wrote:
 > Hi all
 >
 > I am currently authenticating users with Centos 6 and sssd to an LDAP
 > server. I'll be moving to a Centos 8 so have setup sssd to authenticate
 > to the LDAP server on my test Centos 8 box. However, our users in our
 > LDAP only contains all numeric identifiers for users. Centos 8 no longer
 > accepts all numeric user names and group names
 >
 > Currently my sssd.conf contains:
 >
 > ldap_user_uid_number = uid
 > ldap_user_gid_number = uid
 > override_homedir = /homes/%u
 >
 > Our LDAP server contains "uid" values for users like "123456"
 >
 > I'll still be able to use the LDAP "uid" for UNIX uid and gid but what
 > I would like to be able to do is have the user name (and group name)
 > created by prefixing the LDAP "uid" values with a literal "u" to make
 > them POSIX compliant.
 >
 > Hence a user 123456 with "uid" of 123456 in LDAP can login and end up
 > with a username of "u123456".
 > I can't see a way to do that with a simple template in the "man
 > ssd.conf"

How about using fully qualified names instead?

UTS CRICOS Provider Code: 00099F DISCLAIMER: This email message and any 
accompanying attachments may contain confidential information. If you 
are not the intended recipient, do not read, use, disseminate, 
distribute or copy this message or attachments. If you have received 
this message in error, please notify the sender immediately and delete 
this message. Any views expressed in this message are those of the 
individual sender, except where the sender expressly, and with 
authority, states them to be the views of the University of Technology 
Sydney. Before opening any attachments, please check them for viruses 
and defects. Think. Green. Do. Please consider the environment before 
printing this email.

___
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] Heads up. Moving to github. (Date to be set)

[Pavel Březina]

SSSD repository is currently spread over multiple places. We use Pagure 
[1][2] to manage upstream issues and documentation and Github [3] as our 
main development platform.


We chose to move only to a single platform to reduce number of tools we 
use and to have everything at one place. We decided to move from Pagure 
to Github.


This is only a heads up. Precise date will be set soon and I will notify 
you on sssd-users and sssd-devel mailing lists.


There are several steps that needs to be done in order to achieve this 
change but the most significant for our users and contributors is: We 
will no longer accept new issues and pull request in Pagure and we will 
kindly ask you to use Github instead.


Thank you.

Best regards,
Pavel.

[1] https://pagure.io/SSSD/sssd
[2] https://pagure.io/SSSD/docs
[3] https://github.com/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://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] Heads up. Moving to github on April 8

[Pavel Březina]

SSSD repository is currently spread over multiple places. We use Pagure 
[1][2] to manage upstream issues and documentation and Github [3] as our 
main development platform.


We chose to move only to a single platform to reduce number of tools we 
use and to have everything at one place. We decided to move from Pagure 
to Github.


There are several steps that needs to be done in order to achieve this 
change but the most significant for our users and contributors is: We 
will no longer accept new issues and pull request in Pagure and we will 
kindly ask you to use Github instead.


I will disable issues and pull request on Pagure and enable issues on 
Github on Wednesday, April 8.


Thank you.

Best regards,
Pavel.

[1] https://pagure.io/SSSD/sssd
[2] https://pagure.io/SSSD/docs
[3] https://github.com/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://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: Heads up. Moving to github on April 8

[Pavel Březina]

On 4/3/20 1:40 PM, Lukas Slebodnik wrote:

On (03/04/20 13:12), Pavel Březina wrote:

SSSD repository is currently spread over multiple places. We use Pagure
[1][2] to manage upstream issues and documentation and Github [3] as our main
development platform.

We chose to move only to a single platform to reduce number of tools we use
and to have everything at one place. We decided to move from Pagure to
Github.

There are several steps that needs to be done in order to achieve this change
but the most significant for our users and contributors is: We will no longer
accept new issues and pull request in Pagure and we will kindly ask you to
use Github instead.

I will disable issues and pull request on Pagure and enable issues on Github
on Wednesday, April 8.


Issue tracker was opened on github.

Old issues will be kept in Pagure so we can communicate with original 
reporters (Github does not support Fedora Account so we can not simply 
migrate them). Unfortunately 'New issue' button is still available on 
Pagure - there does not seem to be a way how to disable new issues 
without making the issues read only. But please, report new issues 
against Github.



Old issues from fdorahosted are still accesible because they are redirected to
pagure e.g.
https://fedorahosted.org/sssd/ticket/2846 -> 
https://pagure.io/SSSD/sssd/issue/2846

And issues from fedorahosted/pagure are available on many places bugzilla/mail
archive ...

What is a plan with migrating/redirecting issues?


Because Github does not support Fedora Accounts and we would like to be 
able to communicate with original reporters old issues will be still 
available on Pagure until they are all resolved. So old issues will not 
be migrated and the links will keep working.




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://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: Heads up. Moving to github on April 8

[Pavel Březina]

On 4/9/20 2:36 PM, Andreas Hasenack wrote:

hello,

On Thu, Apr 9, 2020 at 9:33 AM Pavel Březina  wrote:

Issue tracker was opened on github.

Old issues will be kept in Pagure so we can communicate with original
reporters (Github does not support Fedora Account so we can not simply
migrate them). Unfortunately 'New issue' button is still available on
Pagure - there does not seem to be a way how to disable new issues
without making the issues read only. But please, report new issues
against Github.


If pagure has this feature, could you perhaps add a template for
issues on pagure that basically says to open them in github instead?


This is a good idea, thank you.

It seems that Pagure supports it but it requires a file in templates 
folder in the repository. I will do this once we migrate releases so we 
can stop using Pagure repository. At that time, it will be possible to 
have a special commit for Pagure that will contain stronger message and 
issue template.



___
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] Heads up. We are migrating issues to Github on May 2-3.

[Pavel Březina]

This is a continuation of SSSD migration from Pagure to Github.

We reconsidered our previous decision to keep existing issues in Pagure 
and we chose to clone all issues to github instead. As much as we would 
like to keep in touch with users on Pagure we are not able to close 
remaining tickets in reasonable amount of time and having increased 
number of issue trackers would drive us crazy instead of becoming more 
efficient.


All existing issues (both open and closed) will be cloned to github this 
weekend (May 2-3). Please, disable notifications from our github 
repository [1] for this weekend by clicking on "unwatch" button 
otherwise you will get several thousand of notifications.


You might have already got some notification from migration test (from 
pbrezina/sssd-test repository) if you have the same username in Pagure 
and Github and you were @mentioned in the ticket. Please, ignore those.


Issues on Pagure will be marked read only after this weekend and we will 
only accept new issues on Github.


Thank you for understanding and I apologize for any inconvenience.

[1] https://github.com/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://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: Heads up. We are migrating issues to Github on May 2-3.

[Pavel Březina]

On 4/29/20 1:24 PM, Lukas Slebodnik wrote:

On (28/04/20 13:27), Pavel Březina wrote:

This is a continuation of SSSD migration from Pagure to Github.

We reconsidered our previous decision to keep existing issues in Pagure and
we chose to clone all issues to github instead. As much as we would like to
keep in touch with users on Pagure we are not able to close remaining tickets
in reasonable amount of time and having increased number of issue trackers
would drive us crazy instead of becoming more efficient.

All existing issues (both open and closed) will be cloned to github this
weekend (May 2-3). Please, disable notifications from our github repository
[1] for this weekend by clicking on "unwatch" button otherwise you will get
several thousand of notifications.

You might have already got some notification from migration test (from
pbrezina/sssd-test repository) if you have the same username in Pagure and
Github and you were @mentioned in the ticket. Please, ignore those.

Issues on Pagure will be marked read only after this weekend and we will only
accept new issues on Github.

Thank you for understanding and I apologize for any inconvenience.



Old issues from fdorahosted are still accesible because they are redirected to
pagure e.g.
https://fedorahosted.org/sssd/ticket/2846 ->
https://pagure.io/SSSD/sssd/issue/2846
 
And issues from fedorahosted/pagure are available on many places bugzilla/mail

archive ...
 
What is a plan with redirecting URLs from fedorahosted/pagure?


There won't be redirection but it will be cross referenced.


Will be the ID of old issue the same as new on github?


IDs will be different.



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://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] Announcing SSSD 2.3.0

[Pavel Březina]

# SSSD 2.3.0

The SSSD team is proud to announce the release of version 2.3.0 of the
System Security Services Daemon. The tarball can be downloaded from:
https://github.com/SSSD/sssd/releases/tag/sssd-2_3_0

See the full release notes at:
https://sssd.github.io/docs/users/relnotes/notes_2_3_0

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### New features

- SSSD can now handle `hosts` and `networks` nsswitch databases (see 
`resolve_provider` option)
- By default, authentication request only refresh user's initgroups if 
it is expired or there is not active user's session (see 
`pam_initgroups_scheme` option)

- OpenSSL is used as default crypto provider, NSS is deprecated
- Active Directory provider now defaults to GSS-SPNEGO SASL mechanism 
(see `ldap_sasl_mech` option)
- Active Directory provider can now be configured to use only `ldaps` 
port (see `ad_use_ldaps` option)

- SSSD now accepts host entries from GPO's security filter
- Format of debug messages has changed to be shorter and better sortable
- New debug level (`0x1`) was added for low level ldb messages only 
(see `sssd.conf` man page)


### Packaging changes

- New configure option `--enable-gss-spnego-for-zero-maxssf`

### Documentation Changes

- Default value of `ldap_sasl_mech` has changed to `GSS-SPNEGO` for AD 
provider

- Return code of `pam_sss.so` are documented in `pam_sss` manpage
- Added option `ad_update_samba_machine_account_password`
- Added option `ad_use_ldaps`
- Added option `ldap_iphost_object_class`
- Added option `ldap_iphost_name`
- Added option `ldap_iphost_number`
- Added option `ldap_ipnetwork_object_class`
- Added option `ldap_ipnetwork_name`
- Added option `ldap_ipnetwork_number`
- Added option `ldap_iphost_search_base`
- Added option `ldap_ipnetwork_search_base`
- Added option `ldap_connection_expire_offset`
- Added option `ldap_sasl_maxssf`
- Added option `pam_initgroups_scheme`
- Added option `entry_cache_resolver_timeout`
- Added option `entry_cache_computer_timeout`
- Added option `resolver_provider`
- Added option `proxy_resolver_lib_name`
- Minor text improvements
___
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] SSSD has moved to Github

[Pavel Březina]

I'm glad to announced that we have finished our migration to Github. The 
repository and documentation on Pagure is no longer used.


The code is available at https://github.com/SSSD/sssd and documentation 
at https://sssd.io.

___
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] Announcing SSSD 2.3.1

[Pavel Březina]

# SSSD 2.3.1

The SSSD team is proud to announce the release of version 2.3.1 of the
System Security Services Daemon. The tarball can be downloaded from:
 https://github.com/SSSD/sssd/releases/tag/sssd-2_3_1

See the full release notes at:
 https://sssd.io/docs/users/relnotes/notes_2_3_1

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### New features

- Domains can be now explicitly enabled or disabled using `enable` option in
  domain section. This can be especially used in configuration snippets.
- New configuration options `memcache_size_passwd`, `memcache_size_group`,
  `memcache_size_initgroups` that can be used to control memory cache size.

### Notable bug fixes

- Fixed several regressions in GPO processing introduced in sssd-2.3.0
- Fixed regression in PAM responder: failures in cache only lookups are 
no longer considered fatal
- Fixed regression in proxy provider: `pwfield=x` is now default value 
only for `sssd-shadowutils` target


### Packaging changes

- `libwbclient` is now deprecated and is not being built by default (use 
`--with-libwibclient` to build it)


### Documentation Changes

- Added option `memcache_size_passwd`
- Added option `memcache_size_group`
- Added option `memcache_size_initgroups`
- Added option `enable` in domain sections
- Minor text improvements
___
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: Does sssd use initgroups?

[Pavel Březina]

On 7/27/20 11:07 AM, Lukas Slebodnik wrote:

On (26/07/20 12:08), Spike White wrote:

All,

sssd front-end, AD back-end.Does sssd use initgroups to use initial
group membership?

I was recently debugging a sssd connection problem in the
/var/log/sssd/sssd* logs (debug level 9).  and I thought I saw a reference
to initgroups.  or getgrouplist().

my /etc/nsswitch.conf file has:

  passwd:  files systemd sss
  group:  files systemd sss

Should I also have a line with:

  initgroups:  files systemd sss



glibc will try to use all possible modules if initgroups is missing in
/etc/nsswitch.conf.

I would not recommend adding such line to nsswitch.conf


If initgroups line is present it behaves quite differently then what you 
would expected and you need to add [SUCCESS=continue] after each module 
to get the same result.


If it is not preset it default to "group" map with sane behavior.

This is nice explanation of the problem:
https://bugs.gentoo.org/682314#c2
___
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_provider=ldap with auth_provider=proxy

[Pavel Březina]

On 7/23/20 5:57 AM, Jonathon Anderson wrote:

I'm working a RHEL7.6 case (02704264, if that's useful to anyone)
where the tech is claiming that our domain setup of id_provider=ldap
with auth_provider=proxy doesn't work. This is counter to our past and
current experience, but I'm afraid of this being a red herring that
will block us from troubleshooting the hanging issue we're
experiencing.

The tech is citing table 7.1 at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/configuring_domains,
which lists "Available Combinations of Identity and Authentication
Providers" and, since this combination isn't listed, they're saying
this combination doesn't work.

We use auth_provider=proxy to dispatch auth through a Duo authentication proxy.

Can someone confirm whether there's any reason this shouldn't work?
Again, it *does* work, but we're experiencing a failure mode where
sssd becomes unresponsive after some time or event, as yet
undetermined.

Thanks for your help.


I don't think there is anything that prevents this combination to work.

But it may be unsupported. untested combination from RHEL perspective.

___
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 auth and system upgrades

[Pavel Březina]

On 7/29/20 5:27 PM, xcor...@gmail.com wrote:

I've been using sssd + AD to do auth for a few years now. Offline 
authentication is enabled and works normally. In that time I've upgraded my 
Ubuntu laptop several times, and each time I noticed that after the update, I 
cannot log in unless I'm on the corp network with direct access to AD. That 
hasn't really been a problem until now. I'm working from home over vpn all the 
time and don't have to option of going in to get on the corp network.

I know the workaround is to use a local account, get on the VPN, authenticate with 
my AD account and populate the cache, but IT doesn't like me creating local users 
and it's a pain. I haven't tried the latest update yet (19.10 -> 20.04, sssd 
currently 2.2.0).

Since something in the upgrade process is presumably destroying the cache, I was 
wondering if there's a "nice" way around this? Ubuntu upgrades for sssd seem 
like they're just upgrading sssd via apt, so I'm wondering why these major updates seem 
to operate differently from minor ones, and if that's intentional.


SSSD itself certainly does not destroy any cached content during 
updates. We takes lots of care to keep the cache working. Even if we did 
some incompatible changes in the cache format we just update it first 
time SSSD is run and no data is thrown away.


Is it possible that Ubuntu removes the old cache as part of the upgrade 
process?

___
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] Announcing SSSD 2.4.0

[Pavel Březina]

# SSSD 2.4.0

The SSSD team is proud to announce the release of version 2.4.0 of the
System Security Services Daemon. The tarball can be downloaded from:
https://github.com/SSSD/sssd/releases/tag/sssd-2_4_0

See the full release notes at:
https://sssd.io/docs/users/relnotes/notes_2_4_0

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

- `libnss` support was dropped, SSSD now supports only `openssl` 
cryptography


### New features

- Session recording can now exclude specific users or groups when 
`scope` is set to `all` (see `exclude_users` and `exclude_groups` options)
- Active Directory provider now sends CLDAP pings over UDP protocol to 
Domain Controllers in parallel to determine site and forest to speed up 
server discovery


### Packaging changes

- python2 bindings are disable by default, use `--with-python2-bindings` 
to build it


### Documentation Changes

- Default value of `client_idle_timeout` changed from 60 to 300 seconds 
for KCM, this allows more time for user interaction (e.g. during `kinit`)
- Added `exclude_users` and `exclude_groups` option to 
`session_recording` section, this allows to exclude user or groups from 
session recording when `scope` is set to `all`
- Added `ldap_library_debug_level` option to enable debug messages from 
`libldap`
- Added `dyndns_auth_ptr` to set authentication mechanism for PTR DNS 
records update
- Added `ad_allow_remote_domain_local_groups` to be compatible with 
other solutions

___
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] Announcing SSSD 2.4.1

[Pavel Březina]

# SSSD 2.4.1

The SSSD team is proud to announce the release of version 2.4.1 of the
System Security Services Daemon. The tarball can be downloaded from:
https://github.com/SSSD/sssd/releases/tag/2.4.1

See the full release notes at:
https://sssd.io/docs/users/relnotes/notes_2_4_1

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### General information

* `SYSLOG_IDENTIFIER` was renamed to `SSSD_PRG_NAME` in journald output, 
to avoid issues with PID parsing in rsyslog (BSD-style forwarder) output.


### New features

* New PAM module `pam_sss_gss` for authentication using GSSAPI
* `case_sensitive=Preserving` can now be set for trusted domains with AD 
provider
* `case_sensitive=Preserving` can now be set for trusted domains with 
IPA provider. However, the option needs to be set to `Preserving` on 
both client and the server for it to take effect.

* `case_sensitive` option can be now inherited by subdomains
* `case_sensitive` can be now set separately for each subdomain in 
`[domain/parent/subdomain]` section
* `krb5_use_subdomain_realm=True` can now be used when sub-domain user 
principal names have upnSuffixes which are not known in the parent 
domain. SSSD will try to send the Kerberos request directly to a KDC of 
the sub-domain.


### Important fixes

* krb5_child uses proper umask for DIR type ccaches
* Memory leak in the simple access provider
* KCM performance has improved dramatically for cases where large amount 
of credentials are stored in the ccache.


### Packaging changes

* Added `pam_sss_gss.so` PAM module and `pam_sss_gss.8` manual page

### Configuration changes

* New default value of `debug_level` is 0x0070
* Added `pam_gssapi_check_upn` to enforce authentication only with 
principal that can be associated with target user.
* Added `pam_gssapi_services` to list PAM services that can authenticate 
using GSSAPI

___
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: sudo (with sssd) command duration 50ms -> 400ms performance degradation

[Pavel Březina]

On 1/22/21 3:11 PM, Judd Gaddie wrote:

Is there any way to use nsswitch or another mechanism to not bother using sss 
when it matches a sudo rule locally?

Something like sudoers: files [SUCCESS=return] sss


I don't think that sudo supports this.


I am looking for a way to bypass sssd's performance issues by using local 
sudoers files while at the same time still having sss for other rules.


Can you share sudo and sssd log files?
https://sssd.io/docs/users/troubleshooting/sudo_troubleshooting.html

Do you have only local sudoers or also some rules in LDAP?
___
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] Announcing SSSD 2.4.2

[Pavel Březina]

# SSSD 2.4.2

The SSSD team is proud to announce the release of version 2.4.2 of the
System Security Services Daemon. The tarball can be downloaded from:
 https://github.com/SSSD/sssd/releases/tag/2.4.2

See the full release notes at:
 https://sssd.io/docs/users/relnotes/notes_2_4_2

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### General information

* Default value of 'user' config option was fixed into accordance with 
man page, i.e. default is 'root'
* Example systemd service configs now makes use of CapabilityBoundingSet 
option as a security hardening measure.


### New features

* `pam_sss_gss` now support authentication indicators to further harden 
the authentication


### Configuration changes

* Added `pam_gssapi_indicators_map` to configure authentication 
indicators requirements

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] sssd: new project website

[Pavel Březina]

I am proud to announce that the new project website is online at:
https://sssd.io

We've worked hard the last couple of months to update our current 
documentation and bring better user experience.


What's new:
* All content is now up to date with latest SSSD version
* New contribution guide so new contributors (both internal and 
external) can quickly pick up on SSSD specifics

* New user-facing content

We will keep adding new content in the following months. You can also 
contribute to the documentation by submitting pull requests to this 
repository:

https://github.com/SSSD/sssd.io

We will try hard to keep to documentation up to date to make it more 
useful for the community.

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Announcing SSSD 2.5.0

[Pavel Březina]

# SSSD 2.5.0

The SSSD team is proud to announce the release of version 2.5.0 of the
System Security Services Daemon. The tarball can be downloaded from:
https://github.com/SSSD/sssd/releases/tag/2.5.0

See the full release notes at:
https://sssd.io/release-notes/sssd-2.5.0.html

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### General information

* `secrets` support is deprecated and will be removed in one of the next 
versions of SSSD.
* `local-provider` is deprecated and will be removed in one of the next 
versions of SSSD.
* SSSD's implementation of `libwbclient` was removed as incompatible 
with modern version of Samba.
* This release deprecates `pcre1` support. This support will be removed 
completely in following releases.
* A home directory from a dedicated user override, either local or 
centrally managed by IPA, will have a higher precedence than the 
`override_homedir` option.
* `debug-to-files`, `debug-to-stderr` command line and undocumented 
`debug_to_files` config options were removed.


### New features

* Added support for automatic renewal of renewable TGTs that are stored 
in KCM ccache. This can be enabled by setting `tgt_renewal = true`. See 
the sssd-kcm man page for more details. This feature requires MIT 
Kerberos krb5-1.19-0.beta2.3 or higher.
* Backround sudo periodic tasks (smart and full refresh) periods are now 
extended by a random offset to spread the load on the server in 
environments with many clients. The random offset can be changed with 
`ldap_sudo_random_offset`.
* Completing a sudo full refresh now postpones the smart refresh by 
`ldap_sudo_smart_refresh_interval` value. This ensure that the smart 
refresh is not run too soon after a successful full refresh.
* If `debug_backtrace_enabled` is set to `true` then on any error all 
prior debug messages (to some limit) are printed even if `debug_level` 
is set to low value (for details see `man sssd.conf`: 
`debug_backtrace_enabled` description).
* Besides trusted domains known by the forest root, trusted domains 
known by the local domain are used as well.
* New configuration option `offline_timeout_random_offset` to control 
random factor in backend probing interval when SSSD is in offline mode.


### Important fixes

* `ad_gpo_implicit_deny` is now respected even if there are no 
applicable GPOs present
* During the IPA subdomains request a failure in reading a single 
specific configuration option is not considered fatal and the request 
will continue

* unknown IPA id-range types are not considered as an error
* SSSD spec file `%postun` no longer tries to restart services that can 
not be restarted directly to stop produce systemd warnings


### Configuration changes

* Added `tgt_renewal`, `tgt_renewal_inherit`, and `krb5_*` KCM options 
to enable, and tune behavior of new KCM renewal feature.
* Added `ldap_sudo_random_offset` (default to `30`) to add a random 
offset to backround sudo periodic tasks (smart and full refresh).
* Introduced new option 'debug_backtrace_enabled' to control debug 
backtrace.
* Added `offline_timeout_random_offset` configuration option to control 
maximum size of random offset added to offline timeout SSSD backend 
probing interval.

* Long time deprecated and undocumented `debug_to_files` option was removed.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: Announcing SSSD 2.5.0

[Pavel Březina]

On 5/10/21 5:12 PM, Joakim Tjernlund wrote:

On Mon, 2021-05-10 at 14:53 +, Joakim Tjernlund wrote:

I decided to test new sssd/KCM and this is what I get:

- ssh from non sssd/krb machine to new sssd machine, entered password
~ $ klist
Ticket cache: KCM:1001
Default principal: jo...@infinera.com

Valid starting ExpiresService principal
10/05/21 16:47:32  11/05/21 02:47:32  krbtgt/infinera@infinera.com
renew until 17/05/21 16:47:32
~ $ ksu
ksu: Ccache function not supported: not implemented while selecting the best 
principal

I also have mit-kr5b master installed.

Did I miss something?



krb5 master contains: 
https://github.com/krb5/krb5/commit/795ebba8c039be172ab93cd41105c73ffdba0fdb


but RETRIEVE is not implemented in sssd-kcm. Kerberos should fallback to 
its own function that was used before this commit.




Get a KCM trace for ksu:

(2021-05-10 17:09:47): [kcm] [get_client_cred] (0x4000): Client 
[0x56377e20ead0][14] creds: euid[1001] egid[100] pid[5871] cmd_line['ksu'].
(2021-05-10 17:09:47): [kcm] [get_client_cred] (0x0080): The following failure 
is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [95][Operation not supported].
Please, consider enabling SELinux in your system.
(2021-05-10 17:09:47): [kcm] [setup_client_idle_timer] (0x4000): Idle timer 
re-set for client [0x56377e20ead0][14]
(2021-05-10 17:09:47): [kcm] [accept_fd_handler] (0x0400): Client 
[0x56377e20ead0][14] connected!
(2021-05-10 17:09:47): [kcm] [kcm_input_parse] (0x1000): Received message with 
length 4
(2021-05-10 17:09:47): [kcm] [kcm_get_opt] (0x2000): The client requested 
operation 20
(2021-05-10 17:09:47): [kcm] [kcm_cmd_send] (0x0400): KCM operation 
GET_DEFAULT_CACHE
(2021-05-10 17:09:47): [kcm] [kcm_cmd_send] (0x1000): 0 bytes on KCM input
(2021-05-10 17:09:47): [kcm] [kcm_op_queue_send] (0x0200): Adding request by 
1001 to the wait queue
(2021-05-10 17:09:47): [kcm] [kcm_op_queue_get] (0x1000): No existing queue for 
this ID
(2021-05-10 17:09:47): [kcm] [kcm_op_queue_send] (0x1000): Queue was empty, 
running the request immediately
(2021-05-10 17:09:47): [kcm] [kcm_op_get_default_ccache_send] (0x1000): Getting 
client's default ccache
(2021-05-10 17:09:47): [kcm] [ccdb_secdb_get_default_send] (0x2000): Getting 
the default ccache
(2021-05-10 17:09:47): [kcm] [sss_sec_map_path] (0x1000): Mapping prefix /kcm/
(2021-05-10 17:09:47): [kcm] [kcm_map_url_to_path] (0x1000): User-specific KCM 
path is [/kcm/persistent/1001/default]
(2021-05-10 17:09:47): [kcm] [local_db_dn] (0x2000): Local path for 
[persistent/1001/default] is [cn=default,cn=1001,cn=persistent,cn=kcm]
(2021-05-10 17:09:47): [kcm] [sss_sec_new_req] (0x1000): Local DB path is 
persistent/1001/default
(2021-05-10 17:09:47): [kcm] [secdb_dfl_url_req] (0x2000): Created request for 
URL /kcm/persistent/1001/default
(2021-05-10 17:09:47): [kcm] [sss_sec_get] (0x0400): Retrieving a secret from 
[persistent/1001/default]
(2021-05-10 17:09:47): [kcm] [sss_sec_get] (0x2000): Searching for 
[(|(type=simple)(type=binary))] at [cn=default,cn=1001,cn=persistent,cn=kcm] 
with scope=base
(2021-05-10 17:09:47): [kcm] [sss_sec_get] (0x1000): No secret found
(2021-05-10 17:09:47): [kcm] [sec_get] (0x0040): Cannot retrieve the secret 
[2]: No such file or directory
(2021-05-10 17:09:47): [kcm] [ccdb_secdb_list_send] (0x2000): Listing all 
ccaches
(2021-05-10 17:09:47): [kcm] [sss_sec_map_path] (0x1000): Mapping prefix /kcm/
(2021-05-10 17:09:47): [kcm] [kcm_map_url_to_path] (0x1000): User-specific KCM 
path is [/kcm/persistent/1001/ccache/]
(2021-05-10 17:09:47): [kcm] [local_db_dn] (0x2000): Local path for 
[persistent/1001/ccache/] is [cn=ccache,cn=1001,cn=persistent,cn=kcm]
(2021-05-10 17:09:47): [kcm] [sss_sec_new_req] (0x1000): Local DB path is 
persistent/1001/ccache/
(2021-05-10 17:09:47): [kcm] [secdb_container_url_req] (0x2000): Created 
request for URL /kcm/persistent/1001/ccache/
(2021-05-10 17:09:47): [kcm] [sss_sec_list] (0x0400): Listing keys at 
[persistent/1001/ccache/]
(2021-05-10 17:09:47): [kcm] [sss_sec_list] (0x2000): Searching for 
[(|(type=simple)(type=binary))] at [cn=ccache,cn=1001,cn=persistent,cn=kcm] 
with scope=subtree
(2021-05-10 17:09:47): [kcm] [local_dn_to_path] (0x2000): Secrets path for 
[cn=5005e896-bdfb-4116-8a11-eedacad1fa5b-1001,cn=ccache,cn=1001,cn=persistent,cn=kcm]
 is [5005e896-
bdfb-4116-8a11-eedacad1fa5b-1001]
(2021-05-10 17:09:47): [kcm] [sss_sec_list] (0x1000): Returning 1 secrets
(2021-05-10 17:09:47): [kcm] [ccdb_secdb_list_send] (0x2000): Found 1 ccaches
(2021-05-10 17:09:47): [kcm] [ccdb_secdb_list_send] (0x2000): Listing all 
caches done
(2021-05-10 17:09:47): [kcm] [ccdb_secdb_name_by_uuid_send] (0x2000): 
Translating UUID to name
(2021-05-10 17:09:47): [kcm] [sss_sec_map_path] (0x1000): Mapping prefix /kcm/
(2021-05-10 17:09:47): [kcm] [kcm_map_url_to_path] (0x1000): User-specific KCM 
path is [/kcm/persistent/1001/ccache/]
(2021-05-10 17:09:47): [kcm] [local_db_

[SSSD-users] Re: Announcing SSSD 2.5.0

[Pavel Březina]

On 5/10/21 8:10 PM, Joakim Tjernlund wrote:

On Mon, 2021-05-10 at 16:01 +, Joakim Tjernlund wrote:

On Mon, 2021-05-10 at 17:48 +0200, Pavel Březina wrote:

On 5/10/21 5:12 PM, Joakim Tjernlund wrote:

On Mon, 2021-05-10 at 14:53 +, Joakim Tjernlund wrote:

I decided to test new sssd/KCM and this is what I get:

- ssh from non sssd/krb machine to new sssd machine, entered password
~ $ klist
Ticket cache: KCM:1001
Default principal: jo...@infinera.com

Valid starting ExpiresService principal
10/05/21 16:47:32  11/05/21 02:47:32  krbtgt/infinera@infinera.com
renew until 17/05/21 16:47:32
~ $ ksu
ksu: Ccache function not supported: not implemented while selecting the best 
principal

I also have mit-kr5b master installed.

Did I miss something?



krb5 master contains:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkrb5%2Fkrb5%2Fcommit%2F795ebba8c039be172ab93cd41105c73ffdba0fdb&data=04%7C01%7Cjoakim.tjernlund%40infinera.com%7C93db566696a14db59cce08d913cce404%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C0%7C637562592992020361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8lOd0n%2BRZkuSka%2FSJLMMz7Nz4avCJeenpzz6XhbV5PY%3D&reserved=0

but RETRIEVE is not implemented in sssd-kcm. Kerberos should fallback to
its own function that was used before this commit.


FYI, reverting that commit makes it work.


Thanks for the information. Please, open a ticket against krb5.



  Jocke


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] [RFC] What would you like to see on sssd.io

[Pavel Březina]

Dear SSSD community,
we have recently introduced new SSSD project web page at 
https://sssd.io. We would like to keep adding new content, we have 
plenty of ideas but we would also like to get some tips from you:


What articles would you like to see on the page? What knowledge gaps are 
hard to fill with existing documentation? Feel free to suggest both user 
and developer facing content.


Thanks,
Pavel
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: [RFC] What would you like to see on sssd.io

[Pavel Březina]

I read it as:

- Configuring automount with Kereberos authentication and more automount 
information.

- Using trusted domains with non-qualified names (shortnames).
- How auto-discovery of trusted domains works.
- How auto-discovery of AD site works.

Correct me if I'm wrong. Also I added some more comments bellow.

On 5/13/21 1:05 PM, Paweł Szafer wrote:

Hi,

I'm coming from other OS - Arch Linux. So from my point of view:

  * for NSS you pasted full config file and it is great
https://sssd.io/docs/ad/ad-provider-manual.html#nss-pam-configuration
  * do the same for pam.d config so nobody gets confused


This is problematic, since pam config has little but important 
differences between distributions (I remember a critical security issue 
when some distro copy&pasted Fedora configuration).


We can provide sample config for Fedora since that's what we use but we 
would like to rely on community to provide samples for other distributions.




  * add info on which sssd/krb5 version it was tested, so it would be
easier to troubleshoot if there is too old or too new sssd


Ack.


  * I'd like to see some manual how to properly configure automount with
AD with krb5 ticket authentication
  * some extra info about systemd-automount, if possible, if would work
with DFS etc, as systemd-automount get's more popular (autofs was
for some reason removed from Arch repos :( )
  * maybe what is possible to fetch with GPO for Linux (printers with
CUPS, shares with automount?), I read only this
https://sssd.io/design-pages/active_directory_gpo_integration.html
  * more screenshots how to configure GPO, LDAP schema in Windows eg. I
see in man sssd-ad line "When the autofs provider is set to “ad”,
the RFC2307 schema attribute mapping (nisMap, nisObject, ...) is
used, because these attributes are included in the default Active
Directory schema.". It would be extra feature to read more on your
website with screenshots
  * maybe PAM.D + AD configure of Smartcard implementation
  * I can't find myself in menu schema. I googled this site:
https://sssd.io/design-pages/autofs_integration.html ; I have no
idea how to get there if coming from htttps://sssd.io <http://sssd.io>


Would it help if "List of Design Pages" is highlighted in this case?


Anyway, nowadays SSSD has great docs anyway! Thanks for your work!


Thanks for the feedback.



-
Pawel



śr., 12 maj 2021 o 23:15 Spike White <mailto:spikewhit...@gmail.com>> napisał(a):


Pavel,

To me, what was most helpful in the old documentation was the
architectural discussions embedded in the enhancement requests. 
When the requests were satisfied.


Examples:
      use of short names in non-local domains
      auto-discovery of trusted domains

For instance, until I read that discussion I was unaware that if you
turned off auto-discovery and explicitly defined each child domain,
that sssd would no longer contact the global catalog (GC) and thus,
full membership in universal groups was not found.  Only if you
turned on auto-discovery did the sssd code query the GC.  this is
not intuitive, so having that documentation was a great help.

Another example is the discussion of that better discovery algorithm
for AD DCs.   It came out in a recent sssd release, maybe in the
last 6-9 months.   But I can't find that algorithm discussion now.

Spike

On Wed, May 12, 2021 at 7:15 AM Pavel Březina mailto:pbrez...@redhat.com>> wrote:

Dear SSSD community,
we have recently introduced new SSSD project web page at
https://sssd.io. We would like to keep adding new content, we have
plenty of ideas but we would also like to get some tips from you:

What articles would you like to see on the page? What knowledge
gaps are
hard to fill with existing documentation? Feel free to suggest
both user
and developer facing content.

Thanks,
Pavel
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
<mailto:sssd-users@lists.fedorahosted.org>
To unsubscribe send an email to
sssd-users-le...@lists.fedorahosted.org
<mailto:sssd-users-le...@lists.fedorahosted.org>
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:

https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
<

[SSSD-users] Announcing SSSD 2.5.1

[Pavel Březina]

# SSSD 2.5.01

The SSSD team is proud to announce the release of version 2.5.1 of the
System Security Services Daemon. The tarball can be downloaded from:
https://github.com/SSSD/sssd/releases/tag/2.5.1

See the full release notes at:
https://sssd.io/release-notes/sssd-2.5.1.html

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### New features

* `auto_private_groups` option can be set centrally through ID range 
setting in IPA (see `ipa idrange` commands family). This feature 
requires SSSD update on both client and server. This feature also 
requires `freeipa 4.9.4` and newer.


### Important fixes

* Fix `getsidbyname` issues with IPA users with a user-private-group

### Configuration changes

* Default value of `ldap_sudo_random_offset` changed to `0` (disabled). 
This makes sure that sudo rules are available as soon as possible after 
SSSD start in default configuration.

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] [SSSD] Announcing SSSD 2.5.2

[Pavel Březina]

# SSSD 2.5.2

The SSSD team is proud to announce the release of version 2.5.2 of the
System Security Services Daemon. The tarball can be downloaded from:
 https://github.com/SSSD/sssd/releases/tag/2.5.2

See the full release notes at:
 https://sssd.io/release-notes/sssd-2.5.2.html

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### General information

* `originalADgidNumber` attribute in the SSSD cache is now indexed

### New features

* Debug messages in data provider include a unique request ID that can 
be used to track the request from its start to its end (requires 
`libtevent` >= 0.11.0)


### Important fixes

* Update large files in the files provider in batches to avoid timeouts

### Configuration changes

* Add new config option `fallback_to_nss`
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: D-Bus / SSSD / LDAP authentication from a java application

[Pavel Březina]

On 9/10/21 9:20 AM, Daniil Kirilyuk wrote:

We're developing a java application, which should authenticate users against 
both LDAP and custom formatted files containing user information. Both 
username/password and certificate authentication are planned to be supported. 
Our application should run mainly on RHEL. We were estimating the possibility 
to use SSSD for this purpose. After some investigation it seems, that SSSD can 
be called from java code only via D-Bus. It also seems, that it can be used 
mainly for fetching user information. but not for authentication.

E.g. for fetching user by uid:
dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe 
/org/freedesktop/sssd/infopipe/Users org.freedesktop.sssd.infopipe.Users.FindByName 
string:

For retrieving user groups:
dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe 
/org/freedesktop/sssd/infopipe/Users// 
orgfreedesktop.DBus.Properties.Get string:org.freedesktop.sssd.infopipe.Users.User 
string:groups

For retrieving some extra attributes (after adding them to sssd.conf);
dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe 
/org/freedesktop/sssd/infopipe/Users// orgfreedesktop.DBus.Properties.Get 
string:org.freedesktop.sssd.infopipe.Users.User string:"extraAttributes"

Somewhat promising looks method FindByNameAndCertificate:
dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe 
/org/freedesktop/sssd/infopipe/Users 
org.freedesktop.sssd.infopipe.Users.FindByNameAndCertificate string: 
string:

But as far as I understand, FindByNameAndCertificate just compares string 
representation of a pem certificate and is far from client certificate 
authentication.

Do I understand correctly, that at the moment there is no possibility to 
perform user authentication via D-Bus API through SSSD in LDAP? Or am I missing 
something?


Hi, you are correct. At this moment SSSD does not provide any 
authentication mechanism through D-Bus. Authentication is provided only 
though PAM modules pam_sss.so and pam_sss_gss.so (for gssapi 
authenticaiton).


Also even though we do have support for users and groups over D-Bus, 
depending on your use case it might be better to use system calls that 
goes through nsswitch.conf (like getpwnam/getgrnam; I'm not sure what 
are their Java counterparts)-



___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] [SSSD] Announcing SSSD 2.5.2

[Pavel Březina]

# SSSD 2.6.0

The SSSD team is proud to announce the release of version 2.6.0 of the
System Security Services Daemon. The tarball can be downloaded from:
 https://github.com/SSSD/sssd/releases/tag/2.6.0

See the full release notes at:
 https://sssd.io/release-notes/sssd-2.6.0.html

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### General information

* Support of legacy json format for ccaches was dropped
* Support of long time deprecated `secrets` responder was dropped.
* Support of long time deprecated `local` provider was dropped.
* This release drops support of `--with-unicode-lib` configure option. 
`libunistring` will be used unconditionally for Unicode processing.

* This release removes pcre1 support. pcre2 is used unconditionally.
* p11_child does not stop at the first empty slot when searching for tokens
* A flaw was found in SSSD, where the sssctl command was vulnerable to 
shell command injection via the logs-fetch and cache-expire subcommands. 
This flaw allows an attacker to trick the root user into running a 
specially crafted sssctl command, such as via sudo, to gain root access. 
The highest threat from this vulnerability is to confidentiality, 
integrity, as well as system availability. This patch fixes a flaw by 
replacing `system()` with `execvp()`.


### New features

* Basic support of user's 'subuid and subgid ranges' for IPA provider 
and corresponding plugin for shadow-utils were introduced. Limitations: 
- single subid interval pair (subuid+subgid) per user - idviews aren't 
supported - only forward lookup (user -> subid ranges) Take a note, this 
is MVP of experimental feature. Significant changes might be required 
later, after initial feedback. Corresponding support in shadow-utils was 
merged upstream, but since there is no upstream release available yet, 
SSSD feature isn't built by default. Build can be enabled with 
`--with-subid` configure option. Plugin's install path can be configured 
with `--with-subid-lib-path=` (`${libdir}` by default)


### Important fixes

* KCM now replace the old credential with new one when storing an 
updated credential that is however already present in the ccache to 
avoid unnecessary growth of the ccache.
* Improve mpg search filter to be more reliable with id-overrides and 
the new auto_private_groups options.
* Even if the forest root is disabled for lookups all required internal 
data is initialized to be able to refresh the list of trusted domains in 
the forest from a DC of the forest root.
* ccache files are created with the right ownership during offline 
Smartcard authentication
* AD ping is now sent over `ldap` if `cldap` support is not available 
during build. This helps to build SSSD on distributions without `cldap` 
support in `libldap`.

* CVE-2021-3621

### Configuration changes

* New IPA provider's option `ipa_subid_ranges_search_base` allows 
configuration of search base for user's subid ranges. Default: 
`cn=subids,%basedn`

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] [SSSD] Announcing SSSD 2.6.0

[Pavel Březina]

# SSSD 2.6.0

The SSSD team is proud to announce the release of version 2.6.0 of the
System Security Services Daemon. The tarball can be downloaded from:
 https://github.com/SSSD/sssd/releases/tag/2.6.0

See the full release notes at:
 https://sssd.io/release-notes/sssd-2.6.0.html

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### General information

* Support of legacy json format for ccaches was dropped
* Support of long time deprecated `secrets` responder was dropped.
* Support of long time deprecated `local` provider was dropped.
* This release drops support of `--with-unicode-lib` configure option. 
`libunistring` will be used unconditionally for Unicode processing.

* This release removes pcre1 support. pcre2 is used unconditionally.
* p11_child does not stop at the first empty slot when searching for tokens
* A flaw was found in SSSD, where the sssctl command was vulnerable to 
shell command injection via the logs-fetch and cache-expire subcommands. 
This flaw allows an attacker to trick the root user into running a 
specially crafted sssctl command, such as via sudo, to gain root access. 
The highest threat from this vulnerability is to confidentiality, 
integrity, as well as system availability. This patch fixes a flaw by 
replacing `system()` with `execvp()`.


### New features

* Basic support of user's 'subuid and subgid ranges' for IPA provider 
and corresponding plugin for shadow-utils were introduced. Limitations: 
- single subid interval pair (subuid+subgid) per user - idviews aren't 
supported - only forward lookup (user -> subid ranges) Take a note, this 
is MVP of experimental feature. Significant changes might be required 
later, after initial feedback. Corresponding support in shadow-utils was 
merged upstream, but since there is no upstream release available yet, 
SSSD feature isn't built by default. Build can be enabled with 
`--with-subid` configure option. Plugin's install path can be configured 
with `--with-subid-lib-path=` (`${libdir}` by default)


### Important fixes

* KCM now replace the old credential with new one when storing an 
updated credential that is however already present in the ccache to 
avoid unnecessary growth of the ccache.
* Improve mpg search filter to be more reliable with id-overrides and 
the new auto_private_groups options.
* Even if the forest root is disabled for lookups all required internal 
data is initialized to be able to refresh the list of trusted domains in 
the forest from a DC of the forest root.
* ccache files are created with the right ownership during offline 
Smartcard authentication
* AD ping is now sent over `ldap` if `cldap` support is not available 
during build. This helps to build SSSD on distributions without `cldap` 
support in `libldap`.

* CVE-2021-3621

### Configuration changes

* New IPA provider's option `ipa_subid_ranges_search_base` allows 
configuration of search base for user's subid ranges. Default: 
`cn=subids,%basedn`

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: [SSSD] Announcing SSSD 2.5.2

[Pavel Březina]

Subject contains wrong version number, it should obviously be 2.6.0.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] [SSSD] Announcing SSSD 2.6.1

[Pavel Březina]

# SSSD 2.6.1

The SSSD team is proud to announce the release of version 2.6.1 of the
System Security Services Daemon. The tarball can be downloaded from:
 https://github.com/SSSD/sssd/releases/tag/2.6.1

See the full release notes at:
 https://sssd.io/release-notes/sssd-2.6.1.html

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### New features

* New infopipe method `FindByValidCertificate()` which accepts the 
certificate as input, validates it against configured CAs, and outputs 
the user path on success. This is similar to the existing 
`FindByCertificate()`, but that does not do any trust validation.


### Packaging changes

* `subid ranges` support was enabled by default.

### Configuration changes

* Default value of `ssh_hash_known_hosts` setting was changed to false 
for the sake of consistency with OpenSSH that does not hash host names 
by default.


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] [SSSD] Announcing SSSD 2.6.3

[Pavel Březina]

# SSSD 2.6.3

The SSSD team is proud to announce the release of version 2.6.3 of the
System Security Services Daemon. The tarball can be downloaded from:
 https://github.com/SSSD/sssd/releases/tag/2.6.3

See the full release notes at:
 https://sssd.io/release-notes/sssd-2.6.3.html

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### Important fixes

* A regression introduced in sssd-2.6.2 in the IPA provider that 
prevented users from login was fixed. Access control always denied 
access because the selinux_child returned an unexpected reply.
* A critical regression that prevented authentication of users via AD 
and IPA providers was fixed. LDAP port was reused for Kerberos 
communication and this provider would send incomprehensible information 
to this port.
* When authenticating AD users, backtrace was triggered even though 
everything was working correctly. This was caused by a search in the 
global catalog. Servers from the global catalog are filtered out of the 
list before writing the KDC info file. With this fix, SSSD does not 
attempt to write to the KDC info file when performing a GC lookup.

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] [SSSD] Announcing SSSD 2.7.0

[Pavel Březina]

# SSSD 2.7.0

The SSSD team is proud to announce the release of version 2.7.0 of the
System Security Services Daemon. The tarball can be downloaded from:
 https://github.com/SSSD/sssd/releases/tag/2.7.0

See the full release notes at:
 https://sssd.io/release-notes/sssd-2.7.0.html

RPM packages will be made available for Fedora shortly.


## New pgp key

So far we have been signing each release with our personal keys. 
Starting from this release (including) we have switched to the new 
project key that is used to sign our release tarball.


- Key ID: C13CD07FFB2DB1408E457A3CD3D21B2910CF6759
- URL: https://github.com/SSSD/sssd/blob/2.7.0/contrib/pubkey.asc
- Keyserver: keys.openpgp.org

## Changes release process

We have switched to a more aggressive release process since the release 
of 2.0, where we were trying to publish new features even on every .z 
release. From now on, we want to switch the process again to prioritize 
stabilization of each released version. Therefore .z releases will 
rather focus more on publishing bug fixes and will receive none or only 
very few carefully selected new features.


## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### New features

* Added a new krb5 plugin `idp` and a new binary `oidc_child` which 
performs  **OAuth2** authentication against FreeIPA. This, however, can 
not be tested  yet because this feature is still under development on 
the FreeIPA server  side. Nevertheless, we have decided to include this 
in the release in order to  enable the functionality on the clients 
immediately when the FreeIPA project  delivers this feature without the 
need to update the clients.


### General information

* Better default for IPA/AD re_expression. Tunning for group names 
containing '@' is no longer needed.
* A warning is added in the logs if an LDAP operation needs more than 
80% of the configured timeout.
* A new debug level is added to show statistical and performance data. 
Currently the duration of a backend request and of single LDAP 
operations are recorded if debug_level is set to 9 or the bit 0x2 is 
set.

* Added support for anonymous PKINIT to get FAST credentials
* We have many warnings and errors from static analyzers

### Important fixes

* SSSD now correctly falls back to UPN search if the user was not found 
even with `cache_first = true`.


### Packaging changes

* Added new configure option `--with-oidc-child` and 
`--without-oidc-child` to control build of `oidc_child` (enabled by 
default).
* Added new package `sssd-idp` that contains the `oidc_child` and krb5 
`idp` plugin, this package is required by `sssd-ipa`.

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] [SSSD] Announcing SSSD 2.7.1

[Pavel Březina]

# SSSD 2.7.1

The SSSD team is proud to announce the release of version 2.7.0 of the
System Security Services Daemon. The tarball can be downloaded from:
 https://github.com/SSSD/sssd/releases/tag/2.7.1

See the full release notes at:
 https://sssd.io/release-notes/sssd-2.7.1.html

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### General information

* SSSD can now handle multi-valued RDNs if a unique name must be 
determined with the help of the RDN.


### Important fixes

* A regression in `pam_sss_gss` module causing a failure if `KRB5CCNAME` 
environment variable was not set was fixed.


### Packaging changes

* `sssd-ipa` doesn't require `sssd-idp` anymore

### Configuration changes

* New option `implicit_pac_responder` to control if the PAC responder is 
started for the IPA and AD providers, default is `true`.

* New option `krb5_check_pac` to control the PAC validation behavior.
* multiple `crl_file` arguments can be used in the 
`certificate_verification` 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] [SSSD] Announcing SSSD 2.7.2

[Pavel Březina]

# SSSD 2.7.2

The SSSD team is announcing the release of version 2.7.2 of the
System Security Services Daemon. The tarball can be downloaded from:
 https://github.com/SSSD/sssd/releases/tag/2.7.2

See the full release notes at:
 https://sssd.io/release-notes/sssd-2.7.2.html

*This is a hot fix release* which fixes a serious regression that 
prevented IPA users to log in.


This fix is already included in Fedora packages.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### Important fixes

* A serious regression introduced in `sssd-2.7.1` that prevented 
successful authentication of IPA users was fixed.


### Configuration changes

* Default value of `pac_check` changed to `check_upn, 
check_upn_dns_info_ex` (for AD and IPA 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] [SSSD] Announcing SSSD 2.7.3

[Pavel Březina]

# SSSD 2.7.3

The SSSD team is announcing the release of version 2.7.2 of the
System Security Services Daemon. The tarball can be downloaded from:
 https://github.com/SSSD/sssd/releases/tag/2.7.3

See the full release notes at:
 https://sssd.io/release-notes/sssd-2.7.3.html

*This is a hot fix release* which fixes a serious regression that 
prevented IPA users to log in.


This fix is already included in Fedora packages.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### General information

* All SSSD client libraries (nss, pam, etc) won't serialize requests 
anymore by default, i.e. requests from multiple threads can be executed 
in parallel. Old behavior (serialization) can be enabled by setting 
environment variable "SSS_LOCKFREE" to "NO".

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] [SSSD] Announcing SSSD 2.7.4

[Pavel Březina]

# SSSD 2.7.4

The SSSD team is announcing the release of version 2.7.4 of the
System Security Services Daemon. The tarball can be downloaded from:
 https://github.com/SSSD/sssd/releases/tag/2.7.4

See the full release notes at:
 https://sssd.io/release-notes/sssd-2.7.4.html

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### General information

* Lock-free client support will be only built if libc provides 
`pthread_key_create()` and `pthread_once()`. For glibc this means 
version 2.34+

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] [SSSD] Announcing SSSD 2.8.0

[Pavel Březina]

# SSSD 2.8.0

The SSSD team is announcing the release of version 2.8.0 of the
System Security Services Daemon. The tarball can be downloaded from:
 https://github.com/SSSD/sssd/releases/tag/2.8.0

See the full release notes at:
 https://sssd.io/release-notes/sssd-2.8.0.html

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### General information

* The new D-Bus function ListByAttr() allows the caller to look for 
users that have an attribute with a certain value. For performance 
reasons, it is recommended that the attribute is indexed both on the 
remote server and on the local cache. The sssctl tool now provides the 
cache-index command to help you manage indexes on the local cache.


### New features

* Introduced the dbus function 
org.freedesktop.sssd.infopipe.Users.ListByAttr(attr, value, limit) 
listing upto limit users matching the filter attr=value.
* sssctl is now able to create, list and delete indexes on the local 
caches. Indexes are useful for the new D-Bus ListByAttr() function.
* sssctl is now able to read and set each component's debug level 
independently.


### Important fixes

* `domains` option in `[sssd]` section can now be completely omitted if 
domains are enabled via `domains/enabled` option


### Configuration changes

* New option 'core_dumpable' to manage 'PR_SET_DUMPABLE' flag of SSSD 
processes. Enabled by default.
* New option 'ldap_enumeration_refresh_offset' to set the maximum period 
deviation between enumeration updates. Defaults to 30 seconds.
* New option 'subdomain_refresh_interval_offset' to set the maximum 
period deviation when refreshing the subdomain list.
* New option 'dyndns_refresh_interval_offset' to set the maximum period 
deviation when updating the client's DNS entry. Defaults to 0.
* New option 'refresh_expired_interval_offset' to set the maximum period 
deviation when refreshing expired entries in background.
* New option 'ldap_purge_cache_offset' to set the maximum time deviation 
between cache cleanups. Defaults to 0.
* Option 'ad_machine_account_password_renewal_opts' now accepts an 
optional third part as the maximum deviation in the provided period 
(first part) and initial delay (second part). If the period and initial 
delay are provided but not the offset, the offset is assumed to be 0. If 
no part is provided, the default is 86400:750:300.
* override_homedir now recognizes the %h template which is replaced by 
the original home directory retrieved from the identity provider, but in 
lower case.

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] [SSSD] Announcing SSSD 2.8.1

[Pavel Březina]

# SSSD 2.8.1

The SSSD team is announcing the release of version 2.8.1 of the
System Security Services Daemon. The tarball can be downloaded from:
 https://github.com/SSSD/sssd/releases/tag/2.8.1

See the full release notes at:
 https://sssd.io/release-notes/sssd-2.8.1.html

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### Important fixes

* A regression when running sss_cache when no SSSD domain is enabled 
would produce a syslog critical message was fixed.

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: sssd not using local sudoers file

[Pavel Březina]

On 11/29/22 15:43, Kevin Vasko wrote:

passwd: compat systemd sss
group: compat systemd sss

I changed it to be

passwd: files compat systemd sss
group: files compat systemd sss

and still had the same problem.

id_provider=ipa

Yes Ubuntu.

sssd 2.2.3-3ubuntu0.9

This same named user that was created local is also in our IPA server 
but want this local account and settings on this machine to override that.


-Kevin


On Nov 29, 2022, at 3:03 AM, Alexey Tikhonov  wrote:


Hi,

On Tue, Nov 29, 2022 at 1:10 AM Kevin Vasko > wrote:


We have a local user that has an entry in sudoers for a “NOPASSWD”.

In /etc/nsswitch.conf we have:

sudoers: files sss


What is in 'passwd:' and 'group:'?
Do you use 'id_provider=files' in 'sssd.conf'?


For some reason sssd is falling back to sssd even though we have
the “files” entry first and is checking our FreeIPA instance and
rejecting it and prompts for password.

if I make it

sudoers: files

It works.

This was working without issue on 18.04, we upgraded to 20.04 and
now see the problem.


I guess this is Ubuntu version?
Could you please specify SSSD package versions?


Is there a way to make it prioritize the local sudoers and stop
looking on sssd?


In general, SSSD does not support name collisions. You should make the 
ipa domain to require fully qualified names.


Depending on the problem, there might be a way to solve it. However, I 
must admit, I do not fully understand your issue. Can you be more 
descriptive and provide some examples?


Thank you,
Pavel

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: sssd not using local sudoers file

[Pavel Březina]

On 11/30/22 20:57, Kevin Vasko wrote:
Yup, “files” was first in nsswitch.conf. But now I can’t reproduce it 
because after removing the user1 user from FreeIPA and adding it back, 
it’s working as expected. :-/.


Is it possible that the IPA user had different UID before and now has 
the same UID as the local user?


I'm still going to emphases my original answer: name collisions are not 
supported. There may be some workarounds to solve particular situations, 
but it is never a good idea to have name collisions.


For your particular situation with sudo, you don't have to have local 
user in order to setup sudo rules in /etc/sudoers.




-Kevin


On Nov 30, 2022, at 11:11 AM, Alexey Tikhonov  wrote:



You need to have 'files' first in all nsswitch.conf databases.
If 'sudo' doesn't respect this then this is a bug in 'sudo.

On Wed, Nov 30, 2022 at 5:59 PM Kevin Vasko <mailto:kva...@gmail.com>> wrote:


So for example.

machine1 enrolled in FreeIPA also has userid:
user1 - locally (e.g. useradd)
user1 on machine1 has a defined sudoers of NOPASSWD

FreeIPA also has user1 defined in it.

machine2 enrolled in FreeIPA:
does not have any local accounts.
if user1 logs in, machine2 uses sssd to allow it from freeIPA.

What I want is on machine1 I want it to use _all_ locally
configured settings for user1. I effectively want machine1 to
ignore FreeIPA for user1.

With that being said, I think this is a bug or some weird caching
is happening.

This is a series of even that happened:

* user1 was on machine1 prior to freeIPA and being enrolled into
FreeIPA.
* user1 is a local account and has a NOPASSWD defined for it locally.
* 1 year passes
* freeIPA implemented, user1 account created in FreeIPA
* machine1 enrolled into domain
* user1 and NOPASSWD still working on machine1
* Upgrade Ubuntu from 18.04 to 20.04
* user1 no longer respects local sudoers file NOPASSWD on machine1
and falls back to IPA
* user1 account deleted from FreeIPA
* user1 starts respects sudoers NOPASSWD file on machine1
* user1 account added back to FreeIPA
* user1 still respects sudoers NOPASSWD file on machine1.

So it was working, upgraded to 20.04, stops working, removed
account from FreeIPA, starts working, added account back to
FreeIPA (expecting it to start failing again) but it’s still
working as to how it did prior to 20.04 upgrade.

    -Kevin

> On Nov 30, 2022, at 8:34 AM, Pavel Březina mailto:pbrez...@redhat.com>> wrote:
>
> On 11/29/22 15:43, Kevin Vasko wrote:
>> passwd: compat systemd sss
>> group: compat systemd sss
>> I changed it to be
>> passwd: files compat systemd sss
>> group: files compat systemd sss
>> and still had the same problem.
>> id_provider=ipa
>> Yes Ubuntu.
>> sssd 2.2.3-3ubuntu0.9
>> This same named user that was created local is also in our IPA
server but want this local account and settings on this machine to
override that.
>> -Kevin
>>>> On Nov 29, 2022, at 3:03 AM, Alexey Tikhonov
mailto:atikh...@redhat.com>> wrote:
>>>
>>> 
>>> Hi,
>>>
>>>> On Tue, Nov 29, 2022 at 1:10 AM Kevin Vasko mailto:kva...@gmail.com> <mailto:kva...@gmail.com
<mailto:kva...@gmail.com>>> wrote:
>>>
>>>    We have a local user that has an entry in sudoers for a
“NOPASSWD”.
>>>
>>>    In /etc/nsswitch.conf we have:
>>>
>>>    sudoers: files sss
>>>
>>>
>>> What is in 'passwd:' and 'group:'?
>>> Do you use 'id_provider=files' in 'sssd.conf'?
>>>
>>>
>>>    For some reason sssd is falling back to sssd even though we
have
>>>    the “files” entry first and is checking our FreeIPA
instance and
>>>    rejecting it and prompts for password.
>>>
>>>    if I make it
>>>
>>>    sudoers: files
>>>
>>>    It works.
>>>
>>>    This was working without issue on 18.04, we upgraded to
20.04 and
>>>    now see the problem.
>>>
>>>
>>> I guess this is Ubuntu version?
>>> Could you please specify SSSD package versions?
>>>
>>>
>>>    Is there a way to make it prioritize the local sudoers and stop
>>>    looking on sssd?
>
> In general, SSSD does not support name collisions. You should
make the ipa domain to require fully qualifi

[SSSD-users] Re: sssd not using local sudoers file

[Pavel Březina]

On 12/1/22 16:28, Pavel Březina wrote:

On 11/30/22 20:57, Kevin Vasko wrote:
Yup, “files” was first in nsswitch.conf. But now I can’t reproduce it 
because after removing the user1 user from FreeIPA and adding it back, 
it’s working as expected. :-/.


Is it possible that the IPA user had different UID before and now has 
the same UID as the local user?


Also did the ipa user had any sudo rules defined in ipa? Those might 
have been deleted/disabled when you removed the user.




I'm still going to emphases my original answer: name collisions are not 
supported. There may be some workarounds to solve particular situations, 
but it is never a good idea to have name collisions.


For your particular situation with sudo, you don't have to have local 
user in order to setup sudo rules in /etc/sudoers.




-Kevin

On Nov 30, 2022, at 11:11 AM, Alexey Tikhonov  
wrote:




You need to have 'files' first in all nsswitch.conf databases.
If 'sudo' doesn't respect this then this is a bug in 'sudo.

On Wed, Nov 30, 2022 at 5:59 PM Kevin Vasko <mailto:kva...@gmail.com>> wrote:


    So for example.

    machine1 enrolled in FreeIPA also has userid:
    user1 - locally (e.g. useradd)
    user1 on machine1 has a defined sudoers of NOPASSWD

    FreeIPA also has user1 defined in it.

    machine2 enrolled in FreeIPA:
    does not have any local accounts.
    if user1 logs in, machine2 uses sssd to allow it from freeIPA.

    What I want is on machine1 I want it to use _all_ locally
    configured settings for user1. I effectively want machine1 to
    ignore FreeIPA for user1.

    With that being said, I think this is a bug or some weird caching
    is happening.

    This is a series of even that happened:

    * user1 was on machine1 prior to freeIPA and being enrolled into
    FreeIPA.
    * user1 is a local account and has a NOPASSWD defined for it 
locally.

    * 1 year passes
    * freeIPA implemented, user1 account created in FreeIPA
    * machine1 enrolled into domain
    * user1 and NOPASSWD still working on machine1
    * Upgrade Ubuntu from 18.04 to 20.04
    * user1 no longer respects local sudoers file NOPASSWD on machine1
    and falls back to IPA
    * user1 account deleted from FreeIPA
    * user1 starts respects sudoers NOPASSWD file on machine1
    * user1 account added back to FreeIPA
    * user1 still respects sudoers NOPASSWD file on machine1.

    So it was working, upgraded to 20.04, stops working, removed
    account from FreeIPA, starts working, added account back to
    FreeIPA (expecting it to start failing again) but it’s still
    working as to how it did prior to 20.04 upgrade.

    -Kevin

    > On Nov 30, 2022, at 8:34 AM, Pavel Březina mailto:pbrez...@redhat.com>> wrote:
    >
    > On 11/29/22 15:43, Kevin Vasko wrote:
    >> passwd: compat systemd sss
    >> group: compat systemd sss
    >> I changed it to be
    >> passwd: files compat systemd sss
    >> group: files compat systemd sss
    >> and still had the same problem.
    >> id_provider=ipa
    >> Yes Ubuntu.
    >> sssd 2.2.3-3ubuntu0.9
    >> This same named user that was created local is also in our IPA
    server but want this local account and settings on this machine to
    override that.
    >> -Kevin
    >>>> On Nov 29, 2022, at 3:03 AM, Alexey Tikhonov
    mailto:atikh...@redhat.com>> wrote:
    >>>
    >>> 
    >>> Hi,
    >>>
    >>>> On Tue, Nov 29, 2022 at 1:10 AM Kevin Vasko mailto:kva...@gmail.com> <mailto:kva...@gmail.com
    <mailto:kva...@gmail.com>>> wrote:
    >>>
    >>>    We have a local user that has an entry in sudoers for a
    “NOPASSWD”.
    >>>
    >>>    In /etc/nsswitch.conf we have:
    >>>
    >>>    sudoers: files sss
    >>>
    >>>
    >>> What is in 'passwd:' and 'group:'?
    >>> Do you use 'id_provider=files' in 'sssd.conf'?
    >>>
    >>>
    >>>    For some reason sssd is falling back to sssd even though we
    have
    >>>    the “files” entry first and is checking our FreeIPA
    instance and
    >>>    rejecting it and prompts for password.
    >>>
    >>>    if I make it
    >>>
    >>>    sudoers: files
    >>>
    >>>    It works.
    >>>
    >>>    This was working without issue on 18.04, we upgraded to
    20.04 and
    >>>    now see the problem.
    >>>
    >>>
    >>> I guess this is Ubuntu version?
    >>> Could you please specify SSSD package versions?
    >>>
    >>>
    >>>    Is there a way to make it prioritize the local sudoe

[SSSD-users] [SSSD] Announcing SSSD 2.8.2

[Pavel Březina]

# SSSD 2.8.2

The SSSD team is announcing the release of version 2.8.2 of the
System Security Services Daemon. The tarball can be downloaded from:
 https://github.com/SSSD/sssd/releases/tag/2.8.2

See the full release notes at:
 https://sssd.io/release-notes/sssd-2.8.2.html

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### General information

* SSSD can be configured not to perform a DNS search during DNS name 
resolution. This behavior is governed by the new 
dns_resolver_use_search_list. This parameter can be used in the domain 
section. Default value is true - that means that SSSD follows the system 
settings.
* `--enable-files-domain` configure option is deprecated and will be 
removed in one of the next versions of SSSD.

* `sssctl analyze` tool doesn't require anymore to be run under root.

### New features

* New mapping template for serial number, subject key id, SID, 
certificate hashes and DN components are added to libsss_certmap.

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] [SSSD] Announcing SSSD 2.9.0

[Pavel Březina]

# SSSD 2.9.0

The SSSD team is announcing the release of version 2.9.0 of the
System Security Services Daemon. The tarball can be downloaded from:
 https://github.com/SSSD/sssd/releases/tag/2.9.0

See the full release notes at:
 https://sssd.io/release-notes/sssd-2.9.0.html

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### General information

* `sss_simpleifp` library is deprecated and might be removed in further 
releases. Those who are interested to keep using it awhile should 
configure its build explicitly using `--with-libsifp` `./configure` option.
* "Files provider" (i.e. `id_provider = files`) is deprecated and might 
be removed in further releases. Those who are interested to keep using 
it awhile should configure its build explicitly using 
`--with-files-provider` `./configure` option. Or consider using "Proxy 
provider" with `proxy_lib_name = files` instead.
* Previously deprecated `--enable-files-domain` configure option, which 
was used to manage default value of the `enable_files_domain` config 
option, is now removed.
* Long time unused '--enable-all-experimental-features' configure option 
was removed.
* SSSD will no longer warn about changed defaults when using 
`ldap_schema = rfc2307` and default autofs mapping. This warning was 
introduced in 1.14 to loudly warn about different default values.


### New features

* New passkey functionality, which will allow the use of FIDO2 compliant 
devices to authenticate a centrally managed user locally. Moreover, in 
the case of a FreeIPA user, it can also issue a Kerberos ticket 
automatically with upcoming FreeIPA version 4.11.

* Add support for ldapi:// URLs to allow connections to local LDAP servers
* NSS IDMAP has two new methods: `getsidbyusername` and `getsidbygroupname`

Note: support for passkey is in its initial phase and the authentication 
policy will be adjusted in future versions.


 Packaging changes for passkey

* Include passkey subpackage and dependency for libfido2.

 Configuration changes for passkey

* New options to enable and tune passkey behavior: `pam_passkey_auth`, 
`ldap_user_passkey`, `passkey_verification`, `passkey_child_timeout`, 
`interactive`, `interactive_prompt`, `touch` and `touch_prompt`.
* `--with-passkey` is a new configuration option to enable building 
passkey authentication.



### Important fixes

* A regression when running sss_cache when no SSSD domain is enabled 
would produce a syslog critical message was fixed.


### Configuration changes

* Default value of `cache_first` option was changed to `true` in case 
SSSD is built without `files provider`.
* ipa_access_order parameter introduced. It behaves much like 
ldap_access_order but affects IPA domains (id_provider = ipa) and 
accepts limited values. Please see sssd-ipa(5) for more 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] [SSSD] Announcing SSSD 2.9.1

[Pavel Březina]

# SSSD 2.9.1

The SSSD team is announcing the release of version 2.9.1 of the
System Security Services Daemon. The tarball can be downloaded from:
 https://github.com/SSSD/sssd/releases/tag/2.9.1

See the full release notes at:
 https://sssd.io/release-notes/sssd-2.9.1.html

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### New features

*  Passkey: added option to write key mapping data to file.

### Important fixes

* A regression was fixed that prevented autofs lookups to function 
correctly when cache_first is set to True. Since this was set as a new 
default value in sssd-2.9.1, it is considered as a regression.
* A regression where SSSD failed to properly watch for changes in 
'/etc/resolv.conf' when it was a symbolic link or was a relative path, 
was fixed.

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] [SSSD] Announcing SSSD 2.9.2

[Pavel Březina]

# SSSD 2.9.2

The SSSD team is announcing the release of version 2.9.2 of the
System Security Services Daemon. The tarball can be downloaded from:
 https://github.com/SSSD/sssd/releases/tag/2.9.2

See the full release notes at:
 https://sssd.io/release-notes/sssd-2.9.2.html

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

SSSD 2.9 branch is now in long-term maintenance (LTM) phase.

### General information

* `libkrb5-1.21` can now be used to build PAC plugin.
* `sssctl cert-show` and `cert-show cert-eval-rule` can now be run as 
non-root user.


### Important fixes

* SSSD does no longer crash if PIN is introduced but the tactile trigger 
isn't pressed during passkey authentication.
* SSSD can now recover if memory-cache files under `/var/lib/sss/mc` 
where truncated while SSSD is running.
* Chaining of identical D-Bus requests that run in parallel to avoid 
multiple backend queries works again.


### Configuration changes

* New option `local_auth_policy` is added to control which offline 
authentication methods will be enabled by SSSD. This option is relevant 
for authentication methods which have online, and offline capability 
such as passkey, and smartcard authentication. The default value `match` 
sets the offline methods to their corresponding online value. This 
enables offline authentication when online kerberos pre-authentication 
such as PKINIT, or passkey is supported by the backend, note that online 
methods will still be attempted first. Option value `only` can be used 
to disable online authentication entirely, or the value `enable:method` 
to explicitly enable specific authentication methods, e.g. `enable:passkey`.

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] [SSSD] Announcing SSSD 2.9.3

[Pavel Březina]

# SSSD 2.9.3

The SSSD team is announcing the release of version 2.9.3 of the
System Security Services Daemon. The tarball can be downloaded from:
 https://github.com/SSSD/sssd/releases/tag/2.9.3

See the full release notes at:
 https://sssd.io/release-notes/sssd-2.9.3.html

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

## Highlights

### General information

* The proxy provider is now able to handle certificate mapping and 
matching rules and users handled by the proxy provider can be configured 
for local Smartcard authentication. Besides the mapping rule local 
Smartcard authentication should be enabled with the 'local_auth_policy' 
option in the backend and with 'pam_cert_auth' in the PAM responder.


### Important fixes

Passkey doesn't fail when using FreeIPA server-side authentication and 
require-user-verification=false.


### New features

* When adding a new credential to KCM and the user has already reached 
their limit, the oldest expired credential will be removed to free some 
space. If no expired credential is found to be removed, the operation 
will fail as it happened in the previous versions.

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] [SSSD] Announcing SSSD 2.9.4

[Pavel Březina]

# SSSD 2.9.4

The SSSD team is announcing the release of version 2.9.4 of the
System Security Services Daemon. The tarball can be downloaded from:
 https://github.com/SSSD/sssd/releases/tag/2.9.4

See the full release notes at:
 https://sssd.io/release-notes/sssd-2.9.4.html

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
 https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
 https://lists.fedorahosted.org/mailman/listinfo/sssd-users

# SSSD 2.9.4 Release Notes

## Highlights

### Important fixes

* Fixes a crash when PAM passkey processing incorrectly handles 
non-passkey data.
* A workaround was implemented to handle gracefully misbehaving 
applications that destroy internal state of SSSD client librarires. A 
particular example of such application is described in 
https://github.com/TigerVNC/tigervnc/issues/1709.
* An error when rotating KCM's logs was fixed. When KCM's logs were 
rotated by logrotate, KCM would still use the old file (renamed 
sssd_kcm.log.1). Only after KCM was restarted (either manually or 
automatically) the new log file would be used. This problem is now 
solved and KCM uses the new file immediately.
* Fixed group membership handling when members are coming from 
different forest domains and using ldap token groups is prohibited.
* Files provider was erroneously taking into consideration 
`local_auth_policy` config option, thus breaking smartcard 
authentication of local user in setups that didn't explicitly specify 
this option. This is now fixed.

--
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue