[SSSD-users]Re: realmd: socket activation and sssd.conf's services= line
On Tue, Sep 8, 2020, at 10:53 AM, Andreas Hasenack wrote:
> Hi,
>
> This is more of a realmd question than sssd, but closely related.
>
> Debian and Ubuntu defaulted to socket activated systemd services for
> all the sssd-* daemons. So they are started on demand.
>
> realmd currently always adds a "services = nss, pam" line (or augments
> it if it's there already). sssd will then start nss and pam, but so
> will systemd, and that creates a (apparently harmless) conflict and
> logs errors to the logs.
>
> I don't know if there is a way for realmd to detect this scenario and
> not add that services line, or if there should be a command-line
> option for it? Or maybe something in realm-.conf even?
>
> At the moment I'm just disabling adding the services line. Is this too
> horrible?
In my experience on RHEL 8, some of the services are unreliable when activated
in this manner. The services line never fails. I believe the .service (or
.socket) files on RHEL 8 are written to avoid any collision. Specially, I think
the socket activated version is a no op if the services line one is running.
V/r,
James Cassell
>
> --- a/service/realm-sssd-config.c
> +++ b/service/realm-sssd-config.c
> @@ -154,8 +154,6 @@
> g_strfreev (already);
>
> /* Setup a default sssd section */
> - if (!realm_ini_config_have (config, "section", "services"))
> - realm_ini_config_set (config, "sssd", "services", "nss, pam", NULL);
> if (!realm_ini_config_have (config, "sssd", "config_file_version"))
> realm_ini_config_set (config, "sssd", "config_file_version", "2",
> NULL);
>
> --- a/tests/test-sssd-config.c
> +++ b/tests/test-sssd-config.c
> @@ -90,7 +90,7 @@
> gconstpointer unused)
> {
> const gchar *data = "[domain/one]\nval=1\n[sssd]\ndomains=one";
> - const gchar *check = "[domain/one]\nval=1\n[sssd]\ndomains = one,
> two\nconfig_file_version = 2\nservices = nss, pam\n\n[domain/two]\ndos
> = 2\n";
> + const gchar *check = "[domain/one]\nval=1\n[sssd]\ndomains = one,
> two\nconfig_file_version = 2\n\n[domain/two]\ndos = 2\n";
> GError *error = NULL;
> gchar *output;
> gboolean ret;
> @@ -140,7 +140,7 @@
> test_add_domain_only (Test *test,
>gconstpointer unused)
> {
> - const gchar *check = "\n[sssd]\ndomains = two\nconfig_file_version
> = 2\nservices = nss, pam\n\n[domain/two]\ndos = 2\n";
> + const gchar *check = "\n[sssd]\ndomains = two\nconfig_file_version
> = 2\n\n[domain/two]\ndos = 2\n";
> GError *error = NULL;
> gchar *output;
> gboolean ret;
___
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: Getting 4 (System error) for SSSD clients connected to RODC
On Thu, Jun 4, 2020, at 11:47 AM, Abhijit Tikekar wrote: > Hi all, > > We recently started having issues with some SSSD clients that are > connecting to RODC. They were all working fine when suddenly all > authentications started getting following > > sshd[4487]: pam_sss(sshd:auth): received for user firstname.lastname: 4 > (System error) > Try setting krb5_validate=false in the domain section. V/r, James Cassell > Being a RODC, keytab was created manually on a writable DC using setspn > & ktpass and then integrated on the system using ktutil. Things were > fine until last week when it stopped working on all such systems. We > are not able to identify if the issue is on the system side or AD. > Network side looks good and all required ports are open between client > and Server. Host can also resolve RODC via DNS. Even other utilities > such as ldapsearch, getent, id etc retrieve the results just fine. It > is only the main login process that fails. Attaching parts of logs > generated with debug level 10. > > It would be great if someone can review these and point us in the right > direction. > > _*sssd_domain.log*_ > > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] [dp_attach_req] > (0x0400): Number of active DP request: 1 > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] > [sdap_id_op_connect_step] (0x4000): beginning to connect > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD' > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] [get_server_status] > (0x1000): Status of server 'RODC.x.y.local' is 'name resolved' > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] [get_port_status] > (0x1000): Port status of port 0 for server 'RODC.x.y.local' is 'not > working' > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] [get_port_status] > (0x0080): SSSD is unable to complete the full connection request, this > internal status does not necessarily indicate network port issues. > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] > [fo_resolve_service_send] (0x0020): No available servers for service > 'AD' > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] > [be_resolve_server_done] (0x1000): Server resolution failed: [5]: > Input/output error > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] > [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 > [Input/output error]) > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] [be_mark_offline] > (0x2000): Going offline! > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] [be_mark_offline] > (0x2000): Enable check_if_online_ptask. > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] [be_ptask_enable] > (0x0080): Task [Check if online (periodic)]: already enabled > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] [be_run_offline_cb] > (0x4000): Flag indicates that offline callback were already called. > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] > [sdap_id_op_connect_done] (0x4000): notify offline to op #1 > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] > [ad_subdomains_refresh_connect_done] (0x0020): Unable to connect to > LDAP [11]: Resource temporarily unavailable > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] > [ad_subdomains_refresh_connect_done] (0x0080): No AD server is > available, cannot get the subdomain list while offline > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] [dp_req_done] > (0x0400): DP Request [Subdomains #2]: Request handler finished [0]: > Success > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] [_dp_req_recv] > (0x0400): DP Request [Subdomains #2]: Receiving request data. > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] > [dp_req_reply_list_success] (0x0400): DP Request [Subdomains #2]: > Finished. Success. > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] [dp_req_reply_std] > (0x1000): DP Request [Subdomains #2]: Returning [Provider is Offline]: > 1,1432158212,Offline > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] > [dp_table_value_destructor] (0x0400): Removing [8:8::] from > reply table > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] [dp_req_destructor] > (0x0400): DP Request [Subdomains #2]: Request removed. > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] [dp_req_destructor] > (0x0400): Number of active DP request: 0 > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] > [sdap_id_release_conn_data] (0x4000): releasing unused connection > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] [sbus_dispatch] > (0x4000): dbus conn: 0x55c31927bed0 > (Tue May 26 23:10:52 2020) [sssd[be[x.y.local]]] [be_ptask_offline_cb] > (0x0400): Back end is offline > > _*ldap_child.log*_ > > (Tue May 26 23:10:52 2
[SSSD-users] Re: why does krb5_validate default to false?
On Tue, Apr 21, 2020, at 4:30 AM, Sumit Bose wrote: > On Mon, Apr 20, 2020 at 10:17:31AM -0400, James Cassell wrote: > > > > On Mon, Apr 20, 2020, at 10:09 AM, Andreas Hasenack wrote: > > > Hi, > > > > > > I'm wondering why krb5_validate defaults to false in sssd-krb5, and > > > apparently it's the same default in the mit kerberos libraries (via > > > verify_ap_req_nofail). It should solve the KDC impersonation attack, > > > at the expense of a slightly more complicated setup (create the host > > > principal, extract key, create keytab). Is it because of this added > > > difficulty in setting up things, or does it not work on very common > > > scenarios/applications? Or just one of those hard to do transitions? > > Hi, > > the main reason why krb5_validate is not enable by default in the krb5 > auth provider is basically mentioned below, you need a keytab. Since for > plain classical Kerberos authentication a host keytab is not needed and > might even not be available the validation is off by default. When using > the AD or IPA provider where a keytab is created while joining the > domain validation is switched on by default. > > > > > > > > In my option, krb5_validate is broken. It chooses the name on first key in > > the keytab to attempt validation, rather than either the newest or the one > > matching ldap_sasl_authid (or an equivalent setting.) This causes issues > > where a host may have previously had a service principal but it got > > reassigned to another host, or due to renaming a host without removing the > > old name from the keytab. (RH support considered it "not a bug.") > > I think the most straight forward solution here is to add a new option > to give a principal which should be used for validation. > ldap_sasl_authid is not strictly related, the LDAP code might even use a > different keytab than libkrb5 would use for validation. > I agree having a separate option for configuration here would be useful. I'd never considered that ldap might use a different keytab than kerberos. I wonder why that might be done? > In general /etc/krb5.keytab should only contain entries which are > currently valid. Old entries especially with weak encryption types > should be removed. E.g. sshd is using /etc/krb5.keytab for GSSAPI based > authentication as well so attackers might be able to use information > about the old tickets to get access to your system. > I agree in principle. Practice is harder, especially when dealing with hundreds of legacy systems... If there's a good/easy way to audit keytabs for weak encryption types, it might be worth pursuing... otherwise, I'll pray that FIPS mode saves the day :P V/r, James Cassell ___ 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: why does krb5_validate default to false?
On Mon, Apr 20, 2020, at 10:09 AM, Andreas Hasenack wrote: > Hi, > > I'm wondering why krb5_validate defaults to false in sssd-krb5, and > apparently it's the same default in the mit kerberos libraries (via > verify_ap_req_nofail). It should solve the KDC impersonation attack, > at the expense of a slightly more complicated setup (create the host > principal, extract key, create keytab). Is it because of this added > difficulty in setting up things, or does it not work on very common > scenarios/applications? Or just one of those hard to do transitions? > In my option, krb5_validate is broken. It chooses the name on first key in the keytab to attempt validation, rather than either the newest or the one matching ldap_sasl_authid (or an equivalent setting.) This causes issues where a host may have previously had a service principal but it got reassigned to another host, or due to renaming a host without removing the old name from the keytab. (RH support considered it "not a bug.") V/r, James Cassell ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users]Re: SSSD and PKI: capability of checking trust/validation/revocation
On Wed, Feb 26, 2020, at 4:38 AM, Hristina Marosevic wrote: > 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) SSSD manages all of these. What it does not manage for SSH is whether the certificate from LDAP actually matches the user, which allows users to grant SSH access "as himself" to anyone else in the organization. (If, as in the case of AD, users can modify their own userCertificate attribute. > 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! > > V/r, James Cassell ___ 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: Restricted access to MemberOf attribute in AD
On Thu, Feb 20, 2020, at 4:31 PM, Eugene Vilensky wrote: > > Greetings, > > My company restricts which AD entities have access to a Domain User's > MemberOf attribute. This is done precisely as described by this > institution here: > https://itconnect.uw.edu/wares/msinf/design/arch/group-member-privacy/ > > Self can read own MemberOf. > > We've never seen an impact on Windows clients. > > However for SSSD the effect is obvious: "Domain Users" is the only > Group returned. It appears to be that SSSD uses the permissions of the > Computer account for this operation. > > Is there any configurable alternative to use the User's own permissions > to resolve MemberOf on a user? > I think this info is also in the PAC. I wonder if enabling the pac responder would help... V/r, James Cassell ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users]Re: ldap_id_mapping=False then AD user's password not availabe
On Thu, Feb 6, 2020, at 9:13 PM, Grant Longhurst wrote: > > Out of interest how did you solve it as have the same issue? > I don't see the referenced mail since you didn't quote it, but usually, you need both a uidNumber and gidNumber defined for each user to work everywhere including older sssd version if you're using the ldap_id_mapping=False setting. V/r, James Cassell ___ 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"?
S-S-S-D here. On Fri, Nov 15, 2019, at 7:57 AM, Pavel Březina wrote: > We, developers, always use S-S-S-D. I have never heard anyone saying > Triple-S-D :-) > > 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 mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: sssd PKINIT smartcard auth on RHEL7?
On Fri, Nov 1, 2019, at 8:50 AM, Sumit Bose wrote: > On Fri, Oct 25, 2019 at 08:27:33PM -0400, James Cassell wrote: > > > > On Fri, Oct 25, 2019, at 4:41 PM, James Ralston wrote: > > > On Mon, Oct 21, 2019 at 4:25 PM James Cassell > > > wrote: > > > > I'm in a similar situation... hoping to not write my own nssdb > > > > ansible role, but I'll probably need to write one since I didn't see > > > > a good existing one. > > > > > > I figured out a way to avoid needing to maintain certificates in > > > /etc/pki/nssdb. You only need to do these two things: > > > > > > $ pkcs11-switch opensc > > > $ ln -s /usr/lib64/libnssckbi.so /etc/pki/nssdb/ > > > > > > As long as alternatives is using p11-kit-trust.so: > > > > > > $ alternatives --display libnssckbi.so.x86_64 > > > libnssckbi.so.x86_64 - status is auto. > > > link currently points to /usr/lib64/pkcs11/p11-kit-trust.so > > > /usr/lib64/pkcs11/p11-kit-trust.so - priority 30 > > > /usr/lib64/nss/libnssckbi.so - priority 10 > > > Current `best' version is /usr/lib64/pkcs11/p11-kit-trust.so. > > > > > > …then p11-kit-trust.so will automatically shim the certificate trust > > > database maintained by update-ca-trust(8) into NSSDB. > > > > > > > Awesome, that sounds like a huge time saver! I'm going to try that next > > week. > I tried it out, and it works pretty well. I ended up doing it with `modutil` instead of creating a symlink so that it could be deleted by modutil if it were to become necessary: # modutil -dbdir /etc/pki/nssdb/ -add 'Root Certs' -libfile /usr/lib64/libnssckbi.so (see below for disabling the "Default Trust" certificates an leaving only the "System Trust" certs.) > Hi, > > while this might be a time saver and helps to store the same CA > certificate into various different places I'd like to add a word of > caution here. > Thanks for the push to make it more secure! > When using certificate mapping and matching rules anyone can create a > certificate which matches the rules and matches to any given user. This > means only the CA signature can assure that is really issued by the > expected CA. The system-wide CA database will contain a wide range of CA > certificates mostly to make sure that web-browsing with https works > without much issue. Many of the CA from the system-wide database have > strict procedures and policies to make sure only properly justified > certificates are issued. But you should consider if you would really > trust all those CAs to not issue a fake sub-CA certificate which then ca > be used to create a certificate with allows authentication to your > system. > You can only add the system-customized certificates (aka "System Trust") to the nssdb by disabling the "Default Trust" store: # modutil -dbdir /etc/pki/nssdb/ -disable 'Root Certs' -slot /usr/share/pki/ca-trust-source You can then verify that only your custom Root Certs are trusted: # certutil -L -d /etc/pki/nssdb/ -h all > Please note this is only important if not the full certificate is used > for mapping to the user. Since the full certificate contains the key and > the signature of the CA it cannot be faked. Only if you use single > components from the certificate like e.g. a stored Kerberos principal, > you should take care of the list of trusted CAs. > In effect, with SSSD-AD connection on RHEL 7, it doesn't matter since you need the userCertificate attribute and always match the full cert. (I've opened a Support Case to request the certmap backport to RHEL 7, per this BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1736845 ) V/r, James Cassell ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users]Re: Group disappears from users / no group name gets resolved
On Fri, Oct 18, 2019, at 11:41 AM, Jamal Mahmoud wrote: > Hi Jakub, > > Apologies for the long delay in response as I was dragged away for > other projects! So my previous (false)theory was a result of sssd_nss > not being able to see entries that the sssd_be places into the > memcache. It would not be able to find it's group so it would query any > other domains it could see. I've now been able to isolate the issue > down to an even smaller plausible cause. > > After some digging through logs of an affected machine I've discovered > a very interesting set of logs. This is quite verbose so bear with me. > The command I ran was: > $ getent group $GID > > Here we see NSS requesting a GID number to be resolved/fetched: > (Thu Oct 17 17:02:07 2019) [sssd[nss]] [nss_getby_id] (0x0400): Input > ID: 10 > (Thu Oct 17 17:02:07 2019) [sssd[nss]] [cache_req_send] (0x0400): CR > #187: New request 'Group by ID' > (Thu Oct 17 17:02:07 2019) [sssd[nss]] [cache_req_select_domains] > (0x0400): CR #187: Performing a multi-domain search > (Thu Oct 17 17:02:07 2019) [sssd[nss]] [cache_req_search_domains] > (0x0400): CR #187: Search will check the cache and check the data > provider > > First it checks the NSS cache to see if an entry is present in it's > cache: > (Thu Oct 17 17:02:07 2019) [sssd[nss]] [cache_req_set_domain] (0x0400): > CR #187: Using domain [mydomain.com] > (Thu Oct 17 17:02:07 2019) [sssd[nss]] [cache_req_search_send] > (0x0400): CR #187: Looking up GID:101...@mydomain.com > (Thu Oct 17 17:02:07 2019) [sssd[nss]] [cache_req_search_ncache] > (0x0400): CR #187: Checking negative cache for > [GID:101...@mydomain.com] > (Thu Oct 17 17:02:07 2019) [sssd[nss]] [cache_req_search_ncache] > (0x0400): CR #187: [GID:101...@mydomain.com] is not present in > negative cache > (Thu Oct 17 17:02:07 2019) [sssd[nss]] [cache_req_search_cache] > (0x0400): CR #187: Looking up [GID:101...@mydomain.com] in cache > (Thu Oct 17 17:02:07 2019) [sssd[nss]] [cache_req_search_cache] > (0x0400): CR #187: Object [GID:101...@mydomain.com] was not found > in cache > > It's not present in the cache according to NSS so it requests the > backend to search the domain provider for this entry: > (Thu Oct 17 17:02:07 2019) [sssd[nss]] [cache_req_search_dp] (0x0400): > CR #187: Looking up [GID:101...@mydomain.com] in data provider > (Thu Oct 17 17:02:07 2019) [sssd[nss]] [sss_dp_issue_request] (0x0400): > Issuing request for [0x55ee5f5d1b10:2:101...@mydomain.com] > (Thu Oct 17 17:02:07 2019) [sssd[nss]] [sss_dp_get_account_msg] > (0x0400): Creating request for > [mydomain.com][0x2][BE_REQ_GROUP][idnumber=10:-] > (Thu Oct 17 17:02:07 2019) [sssd[nss]] [sss_dp_internal_get_send] > (0x0400): Entering request [0x55ee5f5d1b10:2:101...@mydomain.com] > > The domain provider finds the entry on the domain and fills the cache: > (Thu Oct 17 17:01:42 2019) [sssd[be[mydomain.com]]] [sdap_save_group] > (0x0400): Storing info for group thegr...@mydomain.com > (Thu Oct 17 17:01:42 2019) [sssd[be[mydomain.com]]] [sysdb_store_group] > (0x1000): The group record of thegr...@mydomain.com did not change, > only updated the timestamp cache > > What's interesting is that the sssd_be tells us that the entry was > already present, yet nss was unaware of any entries in the cache, nss > didn't even say (not exact quote) "entry found, needs updating", which > after some testing on a working machine, is what occurs when nss > encounters an entry that is out of date. > > Here we see sssd_nss responding to the backend's return of the group > entry. > (Thu Oct 17 17:02:07 2019) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got > reply from Data Provider - DP error code: 0 errno: 0 error message: > Success > (Thu Oct 17 17:02:07 2019) [sssd[nss]] [cache_req_search_cache] > (0x0400): CR #187: Looking up [GID:101...@mydomain.com] in cache > (Thu Oct 17 17:02:07 2019) [sssd[nss]] [cache_req_search_cache] > (0x0400): CR #187: Object [GID:101...@mydomain.com] was not found > in cache > > Either the backend is entering data wrongly into the cache or nss is > unable to read certain entries that are placed in the cache, I would > like to think it is the former because the issue is so intermittent and > for the most part, it works correctly. The only workaround we have > found so far is stopping sssd.service, removing the ldbs from > /var/lib/sss/db/ and restarting the service. This allows sssd to work > correctly and return the groups correctly. > Thanks for digging thru this. I've experienced similar behavior, but never chased it down. No further workarounds I've discovered. V/r, James Cassell P.S
[SSSD-users] Re: sssd PKINIT smartcard auth on RHEL7?
On Fri, Oct 25, 2019, at 4:41 PM, James Ralston wrote: > On Mon, Oct 21, 2019 at 4:25 PM James Cassell > wrote: > > PuTTY can do this ticket forwarding. The limiting factor is > > convincing the Active Directory team (or the security team) to > > enable the checkbox "Trust this computer for delegation to any > > service (Kerberos only)" -- there is also an adcli command line > > arg to set this option on Computer Account creation, but I've > > not tried setting it with adcli. I've gotten this working for > > the subset of machines for which InfoSec approved using > > the "Trust this computer for delegation to any > > service (Kerberos only)" checkbox. > > Interesting. Is this a setting on the computer object of the target > host, or on the (Windows) client where PuTTY is being executed? > This is a setting on each Computer object. Delegation is only allowed when connection to machines that have it set, so from my Windows workstation, delegation would work when connecting to some machines but not others depending on the setting for each target machine. Linux doesn't seem to honor the setting, so you can delegate anywhere with `ssh -K` > > (Side note: is there a good guide to setting up NFSv4 w/ auth=krb5p? > > I've been wanting to do this instead of forcing cifs/samba into its > > place... virtually every NFS guide I've found left things > > cleartext.) > > I wasn't able to find a good guide; we had to puzzle out the > configuration ourselves. > > I can try to write up a guide for that (in my copious free time, ha), > but in the meantime, shoot me off-list mail if you have specific > questions. > Thanks for the offer. I know how it goes with free time... > > I was also able to get this [smartcard login] working at the > > console. I didn't do anything special for the console; it just > > worked once the GUI was working. > > I've been able to get /usr/bin/login to prompt for the username/PIN, > but it still fails, even after I enter the correct PIN (that works in > gdm). > > This might be a PAM stack configuration issue, though. I'll have to > dig into it further. > Last I tested this, I think I was using pam_sss solely, not also pam_pkcs11, which is required if you need to enforce smart card login at the machine level (rather than globally in AD.) > > I'm in a similar situation... hoping to not write my own nssdb > > ansible role, but I'll probably need to write one since I didn't see > > a good existing one. > > I figured out a way to avoid needing to maintain certificates in > /etc/pki/nssdb. You only need to do these two things: > > $ pkcs11-switch opensc > $ ln -s /usr/lib64/libnssckbi.so /etc/pki/nssdb/ > > As long as alternatives is using p11-kit-trust.so: > > $ alternatives --display libnssckbi.so.x86_64 > libnssckbi.so.x86_64 - status is auto. > link currently points to /usr/lib64/pkcs11/p11-kit-trust.so > /usr/lib64/pkcs11/p11-kit-trust.so - priority 30 > /usr/lib64/nss/libnssckbi.so - priority 10 > Current `best' version is /usr/lib64/pkcs11/p11-kit-trust.so. > > …then p11-kit-trust.so will automatically shim the certificate trust > database maintained by update-ca-trust(8) into NSSDB. > Awesome, that sounds like a huge time saver! I'm going to try that next week. > > It's [smartcard logins] certainly not going away anytime soon for > > companies who have government, and especially DoD, contracts. > > Alas, yes. > > I did finally get full sssd PKINIT logins working with gdm, BTW. > Congrats! > Thanks to you (and you, Sumit) for your assistance; it was invaluable. > > Next step: to write a guide for this and throw it up somewhere (GitHub > or Pagure) so that others can contribute and expand it… That would be great! V/r, James Cassell ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: sssd PKINIT smartcard auth on RHEL7?
On Mon, Oct 21, 2019, at 1:16 PM, James Ralston wrote: > On Sun, Oct 20, 2019 at 8:54 PM James Cassell > wrote: > > > Even if local authentication works w/o the userCertificate > > attribute, SSH authentication using the Smart Card inherently > > requires the userCertificate attribute because the certificate is > > not sent over the SSH session. > > When you say "SSH authentication using the Smart Card", what exactly > do you mean? > I mean using the private key on the Smart Card as the SSH private key. SSSD will convert the userCertificate into SSH public keys for consumption by openssh. > If you mean being able to ssh to another host after one has logged in, > we don't care about that, because we use gssapi-with-mic/gssapi-keyex > authentication, which bypasses the PAM auth stack entirely. > > A use case we would like to be able to make work is the ability for > Windows users to ssh into Linux hosts. But we expect we will be > unable to get that to work, because: > > 1) There is no Windows SSH client implementation that we know of that > can both perform gssapi-with-mic/gssapi-keyex *and* delegate the > Kerberos credentials. For example, PuTTY can do the former, but > we've never been able to get it to do the latter, which means that > if the user logs in from Windows using PuTTY, they will have no > home directory, because we use autofs-mounted NFSv4 home > directories with auth=krb5p. (No TGT, no home directory.) > PuTTY can do this ticket forwarding. The limiting factor is convincing the Active Directory team (or the security team) to enable the checkbox "Trust this computer for delegation to any service (Kerberos only)" -- there is also an adcli command line arg to set this option on Computer Account creation, but I've not tried setting it with adcli. I've gotten this working for the subset of machines for which InfoSec approved using the "Trust this computer for delegation to any service (Kerberos only)" checkbox. (Side note: is there a good guide to setting up NFSv4 w/ auth=krb5p? I've been wanting to do this instead of forcing cifs/samba into its place... virtually every NFS guide I've found left things cleartext.) > 2) I have no idea if a Windows SSH client exists that can proxy the > smartcard protocol, as la p11-kit: > > https://p11-glue.github.io/p11-glue/p11-kit/manual/remoting.html > Yeah, I'd be interesting in something like that, as well. Theoretically, I could write a (opensc?) plugin/driver that combines a forwarded ssh-agent with a userCertificate from AD/sssd and expose that as a Smart Card, but I'm not sure if that could run within the PAM session, or only afterwards... I briefly looked at using the initial SSH key verification to do a pkinit (without any agent forwarding), but it looks like its signature structure is too strict to leverage as a pkinit attempt. > > nssdb is likely to be required for SSH Smart Card authentication > > Again, I don't think we care about this. > > > > There's a subtle bug in OpenSC that breaks CoolKey-based cards > > > using 2048-bit RSA certificates (which is what we're using): > > > > aha! Did you add the coolkey driver to the nssdb? That could be > > your issue. > > No, I didn't, because I saw nothing in any documentation that stated > this was necessary. > > > The easiest way I know to do that is to install the `opensc` package > > then: > > > > # pkcs11-switch coolkey > > opensc should be used instead of coolkey, as coolkey is deprecated in > RHEL7, and has been removed from RHEL8 entirely. > Yes, I'm using opensc. I only referenced coolkey since you said your cards were coolkey-based. > I can't test in our production environment at the moment, but I have a > test environment that is configured as close to our production > environment as I can make it, and in our test environment: > > $ pkcs11-switch; echo EOF > > EOF > > So, no, /etc/pki/nssdb is not configured to use a PKCS#11 module at > all. > > $ pkcs11-switch opensc; echo EOF > > WARNING: Performing this operation while the browser is running could cause > corruption of your security databases. If the browser is currently running, > you should exit browser before continuing this operation. Type > 'q ' to abort, or to continue: > > Module "OpenSC PKCS #11 Module" added to database. > ERROR: Failed to delete module "CoolKey PKCS #11 Module". > EOF > > $ pkcs11-switch; echo EOF > opensc > EOF > > And, lo and behold, in the test environment gdm now detects a > smartcard insertion and prompts for the pin. > > (In our test environment, PKINIT fails because our AD KDCs aren't > properly co
[SSSD-users] Re: sssd PKINIT smartcard auth on RHEL7?
On Sun, Oct 20, 2019, at 5:38 PM, James Ralston wrote: > On Sat, Oct 19, 2019 at 3:26 AM James Cassell > wrote: > > > On Fri, Oct 18, 2019, at 9:58 PM, James Ralston wrote: > > > > > I am struggling to get smartcard authentication working on RHEL7, > > > using sssd-1.16.4-21.el7 and krb5 PKINIT against Microsoft Active > > > Directory KDCs. > > > > > > Has anyone actually gotten this working? If so, what behavior > > > differences do you see from various login mechanisms (gdm, login, > > > et. al.)? > > > > I've gotten it working. > > > > > Because I see *no* visual differences in any login > > > mechanism. gdm, login, et. al. prompt for a username/password, > > > exactly as before. Both after I enter the username, and after I > > > enter the PIN (at the "password" prompt), there is a delay while > > > sssd pokes at the card. I can also tell this from watching the > > > light on the card reader blink. > > > > I've seen it behave both ways, and I'm not sure what the difference > > was. Sometimes, the GDM login screen automatically shows the > > correct user when the Smart Card is inserted; other times, I must > > first enter the user name before being prompted for the PIN. > > > > I've not seen GDM prompt for a Smart Card, but I'm also not > > enforcing Smart Card-only login at this time. > > I tried disabling password authentication, but the only change I saw > in gdm's behavior was that it skipped the "password" prompt. > > > > If it's really the case that we have to train our users to type > > > their username into the "username" prompt and enter their > > > smartcard PIN into the "password" prompt, we can do that, but that > > > doesn't seem to be how it's supposed to work based on the above > > > documents. And that's going to seem completely horrible to users > > > in contrast to how Windows works, where you walk up, insert your > > > smartcard, and the login screen identifies you and then prompts > > > for your PIN. > > > > The PIN should not be entered into the "Password" prompt. Only the > > prompt that says "PIN" > > OK, good to know. I haven't seen any PIN prompts, so that tells me > gdm isn't even getting to that point in the process. > > > > * I touched /var/lib/sss/pubconf/pam_preauth_available into > > > existence and restarted sssd. > > > > There is no need to perform this step. This is performed > > automatically by sssd when configured with `pam_cert_auth = True` > > Noted. > > > > * I set "pam_cert_auth = true" in the [domain/example.org] section > > > of /etc/sssd/sssd.conf. > > > > This should be in the [pam] section of the sssd.conf > > Hmmm. It seemed to work for me in the [domain] section. (Or at > least, it changed the login behavior.) But I'll go back and try it in > the [pam] section. > > > > * I extracted the correct certificate from my smartcard (the one > > > that krb5.conf is configured to find) and added it to my > > > userCertificate attribute in Active Directory. > > > > This is necessary if you want to use the Smart Card for SSH > > authentication. I'm unsure if it's necessary for authentication > > when the card is physically present at the machine. I know it's not > > necessary with the latest upstream version of SSSD, but not sure if > > it made it into RHEL. > > This feature: > > https://docs.pagure.org/SSSD.sssd/design_pages/certmaps_for_LDAP_AD_file.html#certificate-mapping-and-matching-rules-for-all-providers > > …didn't make it to RHEL7, no. > /me hopes beyond hope that it gets into 7.8 :P > We know that in order for gdm to be able to identify the user > corresponding to the inserted smartcard, sssd needs to be able to map > a smartcard to an AD user. The only way that the RHEL7 version of > sssd knows how to do that is by searching for an AD user object that > has a userCertificate attribute that matches the one on the smartcard. > Thus the requirement to populate userCertificate attributes. > > BUT: if the only consequence of not populating the AD user objects > with the userCertificate attribute is that the user will need to enter > their username before entering their PIN, then we will gleefully avoid > populating our AD user objects with the userCertificate attributes: > > 1. It's another tedious step that has to be performed whenever we > [re]issue] a smartcard. > > 2. Smartcard login on Windows doesn't require
[SSSD-users] Re: sssd PKINIT smartcard auth on RHEL7?
I even populated /etc/pki/nssdb with all of the same certificates > that update-ca-trust maintains, even though I'm not sure that's > necessary, as I think krb5 pkinit.so should handle that. > This is required for SSSD, but not for plain PKINIT. I had to do this to add them to the nssdb store: # certutil -A -n example_ca -t CT,C,C -a -d /etc/pki/nssdb -i example_ca.crt > * I increased various sssd timeouts to work around this bug in sssd > that was derailing the nss responder: > > #4103 slow smartcard interactions break sssd when PKINIT is configured > https://pagure.io/SSSD/sssd/issue/4103 > I'd been considering opening my own bug against pcscd (pcsc-lite?) because of the long delays caused by accessing the card. (Seems like this could be cached.) > I'm open to suggestions for anything that I missed. The thing that solved pkinit for me when logging in on RHEL 7 was the p11_child_timeout in sssd.conf: [pam] p11_child_timeout = 90 Strangely, RHEL 8 did not require that timeout value to be set. The built-in default value is 6 seconds, IIRC. Hope that's helpful, and I'd be interested in hearing about any gotchas you solve along the way. V/r, James Cassell ___ 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: Is there a way to work without AD posix attributes in RH6 and get groups associated not globally?
On Mon, Oct 7, 2019, at 11:00 AM, Spike White wrote: > James, > [Moved response below] > > On Mon, Oct 7, 2019 at 9:51 AM James Cassell > wrote: > > On Mon, Oct 7, 2019, at 10:32 AM, Spike White wrote: > > > James, > > > > > > Let me see if I understand your statement. Suppose my desired UID for > > > admspike_white is 1234. So using POSIX attributes, you had assigned > > > uidNumber == 1234 and gidNumber == 1234 on the user account > > > admspike_white in AD. For each user you had done this. > > > > > > But you had not do the step further and created an actual group object > > > with name 'admspike_white' and gidNumber == 1234. > > > > > > If that's correct, to my mind: > > > > > > 1. without auto_private_groups, your user's account reference to > > > gidNumber == 1234 is a "dangling reference". A reference to a group > > > object that does not exist in your AD deployment. > > > 2. with auto_private_groups, sssd takes the uidNumber (of 1234), > > > invents the fiction of a group with the same name and gidNumber of > > > 1234. id admspike_white reports this fiction as the primary group. In > > > this case, the gidNumber == 1234 would be ignored by sssd (except it'd > > > be reported as one of the supplemental groups in the 'id' command). > > > > > > Do I have this right? > > > > > > > > > All correct except with auto_private_groups, the primary gid shows as the > > gidNumber, but it resolves the group name to the username, so there is no > > nameless group. ...iirc, without the gidNumber, the user failed to resolve > > at all. > > > Yeah ok. But it's not really "resolving" the group name. That is, it's > not looking up in AD for a group with that gidNumber and returning the > name of that group. > By resolving, I meant from an nss perspective. > sssd internally is inventing the fiction of a group with the same group > name as the user name and the same gidNumber as the user's uidNumber. > So with auto_private_groups = true, id would return the same whether > you set gidNumber on the user account or not. (sssd is ignoring that > field for primary group when auto_private_group == true). > Just tested it. Without auto_private_groups = True, sssd fails entirely to resolve users without gidNumber set. Instead,`id user-no-gid` returns "no such user" With `auto_private_groups = True`, it behaves as you describe, "creating" a group named for the user. V/r, James Cassell > Spike > > > > V/r, > > James Cassell > > > > > > > Spike > > > > > > > > > On Fri, Oct 4, 2019 at 11:17 AM Goetz, Patrick G > > wrote: > > > > > > > > > > > > On 10/4/19 8:21 AM, James Cassell wrote: > > > > > We had previously assigned POSIX attributes to all users in AD. We > > assigned a uidNumber to each user and also a gidNumber that is the same > > number as the uidNumber for each given user. > > > > > > > > Wait, you did this in AD? How? I thought all the SIDs need to be > > > > unique because everything in AD is in a single namespace. > > > > > > > > ___ 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: Is there a way to work without AD posix attributes in RH6 and get groups associated not globally?
On Mon, Oct 7, 2019, at 10:32 AM, Spike White wrote: > James, > > Let me see if I understand your statement. Suppose my desired UID for > admspike_white is 1234. So using POSIX attributes, you had assigned > uidNumber == 1234 and gidNumber == 1234 on the user account > admspike_white in AD. For each user you had done this. > > But you had not do the step further and created an actual group object > with name 'admspike_white' and gidNumber == 1234. > > If that's correct, to my mind: > > 1. without auto_private_groups, your user's account reference to > gidNumber == 1234 is a "dangling reference". A reference to a group > object that does not exist in your AD deployment. > 2. with auto_private_groups, sssd takes the uidNumber (of 1234), > invents the fiction of a group with the same name and gidNumber of > 1234. id admspike_white reports this fiction as the primary group. In > this case, the gidNumber == 1234 would be ignored by sssd (except it'd > be reported as one of the supplemental groups in the 'id' command). > > Do I have this right? > All correct except with auto_private_groups, the primary gid shows as the gidNumber, but it resolves the group name to the username, so there is no nameless group. ...iirc, without the gidNumber, the user failed to resolve at all. V/r, James Cassell > Spike > > > On Fri, Oct 4, 2019 at 11:17 AM Goetz, Patrick G > wrote: > > > > > > On 10/4/19 8:21 AM, James Cassell wrote: > > > We had previously assigned POSIX attributes to all users in AD. We > > assigned a uidNumber to each user and also a gidNumber that is the same > > number as the uidNumber for each given user. > > > > Wait, you did this in AD? How? I thought all the SIDs need to be > > unique because everything in AD is in a single namespace. > > > > ___ 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: Is there a way to work without AD posix attributes in RH6 and get groups associated not globally?
On Fri, Oct 4, 2019, at 9:00 AM, Alex Perl wrote: > Hi James, > > Thanks for the update. > Not sure, how auto_private_groups can resolve GID, if for RH6/SSSD1.13 > this attribute has no impact. It does the work quit well for RH7.3 and > up, without any additional settings. > > Can you please elaborate more: "In my example, we assigned uid=gid > attributes unique to each user." > We had previously assigned POSIX attributes to all users in AD. We assigned a uidNumber to each user and also a gidNumber that is the same number as the uidNumber for each given user. Without auto_private_groups, I would have expected `id user` to return a user's primary group name equal to the user name. This did not happen, however, without turning on auto_private_groups; instead, a bare (correct) number was shown for the primary gid, but no name was resolved for that gid. This was on RHEL 7.7, but I'm guessing the behavior is the same on RHEL 6; I'll find out for sure soon. V/r, James Cassell ___ 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: Is there a way to work without AD posix attributes in RH6 and get groups associated not globally?
On Thu, Oct 3, 2019, at 9:15 PM, Alex Perl wrote: > Implemented AD/KRB/SSSD with both RH6 and RH7. > > RH7 no issues, as we are using auto_private_groups that was added to 1.16.1. > > In RH6 the issue ( sssd 1.13 ) is, that all users getting the same > groups and it is a clear security gap. > > The only way to avoid this, based on the KB articles, is to use AD > posix attributes. If we don't waht to use this setup, is there any > other recommended way ? > In my experience, even with AD POSIX attributes where a GID is assigned to the user, the group name does not resolve without auto_private_groups unless there is an associated an AD group with the same GID. In my example, we assigned uid=gid attributes unique to each user. Probably the best way to close the security gap on RH6 is to enforce a umask of 077. > The example of user/group representation, where all users getting the > same gid=273200513(domain users) : > > id username uid=2755191114(ncircle) gid=273200513(domain users) > groups=273200513(domain users) V/r, James Cassell ___ 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: Replacement for Centrify adcert command
On Thu, Aug 15, 2019, at 4:20 AM, Sumit Bose wrote: > On Tue, Aug 13, 2019 at 02:05:06PM -0400, James Cassell wrote: > > Good afternoon, > > > > I'm working on a migration from Centrify to SSSD with Active Directory. > > Everything works quite well except for one item. Centrify has a feature to > > request a certificate from the AD CA that is automatically granted, given > > the AD credentials. This is used for wired 802.1x authentication, among > > other things. > > > > Is there a way to get an AD cert via SSSD or related tools such as adcli? > > (Centrify calls this command 'adcert'.) > > Hi, > > it looks like AD CS with NDES can support SCEP > (https://tools.ietf.org/html/draft-gutmann-scep-14). Please see > https://blogs.technet.microsoft.com/jeffbutte/2016/12/16/236/ for > details. > Thanks for the links! I did take a look at those. It looks like certmonger even supports the same scep protocol, but it seems that it requires a one-time PIN to register, which is an out-of-band manual process as far as I can tell. Red Hat even has some docs on it: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/certmonger-scep Seems like it would be convenient to have the one-time challengePassword (as it's called in the spec) be (derived from) an appropriate kerberos service ticket, (but that's just conjecture.) Somehow, this "just works" on Windows hosts with the auto-enrollment AD policy (as also with Centrify on Linux), but I don't know how; it could be (a variation on) scep for all I know. Thanks for taking a look! V/r, James Cassell > HTH > > bye, > Sumit > > > > > Thanks in advance! > > > > > > V/r, > > James Cassell ___ 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] Replacement for Centrify adcert command
Good afternoon, I'm working on a migration from Centrify to SSSD with Active Directory. Everything works quite well except for one item. Centrify has a feature to request a certificate from the AD CA that is automatically granted, given the AD credentials. This is used for wired 802.1x authentication, among other things. Is there a way to get an AD cert via SSSD or related tools such as adcli? (Centrify calls this command 'adcert'.) Thanks in advance! V/r, James Cassell ___ 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: adcli behavior change with RHEL 7.7
On Thu, Aug 8, 2019, at 1:58 PM, Erinn Looney-Triggs wrote: > Previously when using adcli to join a RHEL <7.7 system to the AD > principles came out in this format: > EXAMPLE$@AD.DOMAIN.COM > > Now when doing a join with adcli we are getting principles in this format: > example$@AD.DOMAIN.COM > > Is this still a legal NETBIOS name? I mean I know it can work, it is > just a string from kerbs perspective, but I was under the impression > that the AD was pretty specific about what it expected the host > principle to be. I am still digging into this, but so far this has > broken some of our kerb code and it appears to have broken adcli update > as well because it is looking for the uppercase principle while only > the lower case principle is available in the keytab. > I'm very happy to see this change. This closely matches with how winbind previously would to do the joins. I don't know the answer to your specific question, but I am happy about the change. V/r, James Cassell ___ 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
