Hello,
I am using SSSD with LDAP directory which provides public keys for each user entry to SSSD.
I am not sure if it is possible to configure SSSD not just to accept the private key (provided by the user during the login) and authenticate the user from LDAP (where his public ke is stored), but also to check the:
- trust (validation of the CA used for signing the user's certificate i.e. public key)
- validity of a user certificate with its public key (its "from" - "to" dates)
- revocation status (configuration of SSSD with CRL lists or OCSP)
or should I manage this on the LDAP side or on application level or somewhere else?
I would be grateful if you share your ideas about the possible solutions of this situation!
BR,
Hristina

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

Dear all,
we're preparing our sssd service to be fully compliant with the patch the
Microsfot will release soon and that will make AD reject any communication
that is not encrypted. ( *ADV190023
<https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023>*
).
We run Scientific Linux 7.4.
openldap-2.4.44-5.el7.x86_64
sssd-ldap-1.14.0-43.el7.x86_64
Our current conf was using TLS like:
> id_provider = ldap
> auth_provider = ldap
[...]
> ldap_tls_cacert = /etc/sssd/root-ca
> ldap_tls_reqcert = allow
> ldap_id_use_start_tls = True
ldap_uri = ldap://ldap:3268
reqcert allow is a security risk, so I consider this conf as a none valid
one *(based on my exprience I can say that we have never used an encrypted
channel. Unfortunately I don't have access to the AD server to see the logs
and I have not sniffed the network to confirm/deny my assumption)*.
I'm now working in two solutions in order to enforce encryption: enforce
TLS or use SSL.
*SSL*
According to https://docs.pagure.org/SSSD.sssd/users/faq.html if I want
to use SSL I need to use ldaps:
This means that if sssd.conf has ldap_uri = ldap://<server>, it will
> attempt to encrypt the communication channel with TLS (transport layer
> security). If sssd.conf has ldap_uri = ldaps://<server>, then SSL will be
> used instead of TLS
So the conf now looks like:
ldaps_uri = ldaps://ldap:3269
then, after deleting all cache and restating service the authentication
service does not work:
# id bria
> id: bria: no such user
following the above guide I found that I had to configure openldap so it
recognizes the RootCA , so I had to create a mozilla db and add the CA in
order to make ldap work:
# grep ^TLS /etc/openldap/ldap.conf
> TLS_CACERTDIR /etc/openldap/cacerts
# certutil -L -d /etc/openldap/cacerts
> Certificate Nickname Trust
> Attributes
>
> SSL,S/MIME,JAR/XPI
> CA CT,C,c
then sssd works again.
> # id bria
> uid=14925(bria)
*TLS*
Same happens if I want to enforce TLS:
ldap_tls_cacert = /etc/sssd/root-ca
> ldap_tls_reqcert = demand
> ldap_id_use_start_tls = True
the cacert is valid cert but it still needs the openldap cacerts db to be
valid in order to talk to the ldap server.
Why is then ldap_tls_cacert = /etc/sssd/root-ca even needed? I can comment
the line and sssd works perfectly.
Is this dependency between sssd and openldap documented in some other place
than the FAQ?
As te logs, even with debug level set to 9, are not saying that much in
regards the SSL/TLS, can anyone confirm that this is how sssd has to be
configured in order to ensure encryption in the communication?
TIA,
--
Arnau Bria

Hi,
I just want to check wether the performance of sssd is alright or if there
is room for improvement.
I am using a binding account to query the Active Directory.
I've configured a nesting level of 1.
When I login the first time or run the id command it takes around 5 secs to
finish when the user is member of ~100 (nested) groups in the AD.
It takes around 10 secs if the user is member of ~200 (nested) groups.
So you can say the loading time is increasing linearly to the membership of
groups.
Unfortunately I need to use a nesting level of 1. I've set group members to
false and enumeration off.
Are these values in an acceptable area? What experiences did you make?
Thank you :)
JM

Hi Sumit,
I've seen the gpo option in the man-pages, but I've got a problem to use it.
I'm supporting several Red-hat/Centos systems for different Teams.
We talk about more than 500 Systems for more than 10 Teams with various
access-rights.
For auditing reasons I'd like to map the system-access-rights to AD-Groups.
Then I'm able to generate audit-reports.
If it's only possible to do this with sssd via gpo, I have to create al
lot of gpo's.
I don't want to use the IDM (IPA) to keep it simple, if it's possible.
Or is this the only/prefered way?
Kind regards
Andreas
On 19.03.2020 16:49, Sumit Bose wrote:
> On Thu, Mar 19, 2020 at 04:12:05PM +0100, Andreas Schoon wrote:
>> Hi,
>>
>> I'm using the sssd (centos7) combined with microsoft ad (2016) and I'm
>> searching for a service-based filter-option.
>>
>> My plan is to grand access to the service, based on groupmembership in ad.
> Hi,
>
> please use sssd-users(a)lists.fedorahosted.org next time.
>
> Please check the ad_gpo_access_control option and the following in man
> sssd-ad. sshd is is by default in ad_gpo_map_remote_interactive and you
> can add the PAM service name of radius e.g. to ad_gpo_map_service.
>
> HTH
>
> bye,
> Sumit
>
>> Is there any way to do this?
>>
>> Example:
>>
>> Member of ad-Group : sssh_user can connect via ssh to the server, Member
>> of ad-Group : rad_user can use the radius-deamon on the server
>>
>> [sshd]
>>
>> ad_access_filter =
>> FOREST:xxx.yy:(memberOf:1.2.840.113556.1.4.1941:=CN=ssh_user,OU=linux,OU=Test,DC=xxx,DC=yy)
>>
>> [radiusd]
>>
>> ad_access_filter =
>> FOREST:xxx.yy:(memberOf:1.2.840.113556.1.4.1941:=CN=rad_user,OU=linux,OU=Test,DC=xxx,DC=yy)
>>
>>
>> I can't see a solution in the manpages ...
>>
>> In the Past I've combined the Groups and used the top one for the
>> filter, but that's not secure ...
>>
>> Kind Regards
>>
>> Andreas
>>
>>
>>
>> --
>> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
>> https://www.avast.com/antivirus
--
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

Hi,
I've sssd running with ldap provider and therefore use a binding account.
In general everything works. I've a question regarding the primary group.
When I login with any user who I permitted to in the sssd.conf all users
have the Domain Users gorup as primary group.
So if I create a file with User a ownership is UserA:Domain\ Users
Same goes for UserB etc.
Can I have influence on the primary group of the sssd users? Because this
seems quite insecure for me. Because I use different permissions for
different users (configured via sudoers files). But if every user is in the
same group..
Thanks for your input!
Jannis

Hey All,
Is there an example of how this bug is triggered?
https://pagure.io/SSSD/sssd/issue/3571
There's a BZ ntry but I can't access it. I'm not able to replicate this
or devise an acceptable scenario using a user/group combination to
trigger it.
So I'm wondering if there's an example AD user/group case that always
triggers this issue.
--
Thx,

Hi All,
I'm using sssd to authenticate users from AD and generally this works fine. However, I have one server that frequently can't resolve AD users:
[root@HOST ~]# id aduser(a)domain.com
id: aduser(a)domain.com: no such user
or:
[aduser@HOST ~]# crontab -l
crontab: your UID isn't in the passwd file.
bailing out.
Around that time I see errors like this in the log:
[sssd[be[domain.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Referral(10), 0000202B: RefErr: DSID-03100781, data 0, 1 access points
ref 1: 'Domain.com'
After a view minutes it works again.
What puzzles me is that I have 2 other servers with the same config using that same user which don't have any problem.
I'm running sssd- 1.16.4. 21.el7_7.1 on CentOS Linux release 7.7.1908 (Core)
This is my sssd.conf:
[sssd]
debug_level=9
sbus_timeout = 30
reconnection_retries = 3
services = nss, pam
config_file_version = 2
domains = domain.com
[pam]
debug_level=9
pam_verbosity = 3
reconnection_retries = 3
[nss]
debug_level=9
reconnection_retries = 3
[domain/domain.com]
debug_level=9
ad_site = SITE
use_fully_qualified_names = true
override_homedir = /home/%u
dyndns_update = false
ldap_schema = ad
id_provider = ad
ad_enabled_domains = sub.domain.com, domain.com
ad_gpo_access_control = disabled
case_sensitive = true
cache_credentials = true
min_id = 1000
ldap_id_mapping = False
ldap_group_nesting_level = 4
ldap_user_primary_group = gidNumber
ad_hostname = host.domain.com
ignore_group_members = TRUE
access_provider = simple
simple_allow_groups = group1@domain.com,group2@sub.domain.com,group3(a)sub.domain.com
Thank you,
Christoph
DISCLAIMER
The content of this email and any files transmitted with it may be confidential and intended solely for the use of the individual named. If you have received this email in error please let us know and delete the content from your system. You may NOT copy or disclose the information to anyone. We do not accept any liability if this email is used for an alternative purpose from which it is intended, nor to any third party in respect thereof. The sender does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
Unless we have agreed otherwise in writing, Sony DADC’s Standard Terms and Conditions of Business will apply to any services and-or disc/home-entertainment related products we provide to you, our Consumer Sales General Conditions will apply to any consumer electronics products we supply to you and our General Conditions of Purchase will apply to any goods and/or services we purchase from you.