from:"Sam Morris"

[SSSD-users] Stability/intended purpose of ccacheFile user attribute

2020-06-28 Thread Sam Morris

/etc/auto.smb is a script used by autofs to make Windows file servers 
accessible to the automounter. The script basically works by by parsing the 
output of 'smbclient -L SERVER'. My workplace has a fairly vanilla FreeIPA 
setup with a one-way trust to an Active Directory domain, and in order for 
smbclient to be able to list a file server's shares, it has to be able to 
access the Kerberos ticket cache of the user who requested the mount in order 
to authenticate to the file servers.

This isn't easy, because the script is launched by autofs, so it doesn't really 
know anything about the user other than its UID and name. The standard script 
just checks in some standard hardcoded locations: 
DIR:/run/user/$AUTOFS_UID/krb5_cc_* and /tmp/krb5cc_$AUTOFS_UID; there's no 
support for other locations, or any of the more interesting credential cache 
types.

I discovered that SSSD has a 'ccacheFile' attribute that points to the location 
of the user's Kerberos ticket cache. After adding '+ccacheFile' to 
[ifp]user_attributes in sssd.conf and restarting sssd, the following patch to 
/etc/auto.smb  got things working.

The patch is pretty straightforward, it just retrieves the ccacheFile attribute 
via the sssd infopipe API:

--- /usr/share/autofs/conffiles/auto.smb2020-01-15 22:04:23.0 
+
+++ /etc/auto.smb   2020-06-28 19:07:01.941702373 +0100
@@ -24,7 +24,19 @@
 
 get_krb5_cache() {
 cache=
-uid=${UID}
+uid=${AUTOFS_UID}
+# This requires busctl, jq, sssd's infopipe responder, and for sssd.conf 
to contain [ifp]user_attributes = +ccacheFile
+# ... maybe we should just su to the user to run smbclient?
+if [[ -x /usr/bin/busctl ]] && [[ -x /usr/bin/jq ]]; then
+_user_obj=$(busctl -j call org.freedesktop.sssd.infopipe 
/org/freedesktop/sssd/infopipe/Users org.freedesktop.sssd.infopipe.Users 
FindByID u "$uid" | jq -r '.data[0]')
+if [[ -n $_user_obj ]]; then
+cache=$(busctl -j get-property org.freedesktop.sssd.infopipe 
"$_user_obj" org.freedesktop.sssd.infopipe.Users.User extraAttributes | jq -r 
'.data.ccacheFile[0]')
+if [[ -n $cache ]]; then
+return
+fi
+fi
+fi
 for x in $(ls -d /run/user/$uid/krb5cc_* 2>/dev/null); do
 if [ -d "$x" ] && klist -s DIR:"$x"; then
cache=DIR:$x

So, I come to this list to find out whether this is a good idea or not: is this 
attribute an implementation detail, or something that a client of sssd can rely 
upon? If not, would you consider making it stable, or provide another mechanism 
to retrieve a user's Kerberos credential cache location--or else propose 
another mechanism (e.g., I suppose the script _could_ use runuser, su or sudo, 
etc., to run smbclient as the requesting user, which would automatically pick 
up KRB5CCNAME via pam_sssd.so)... would that be a better way to do this?

(It appears that the cifs code within the kernel itself has a similar problem; 
it is able to find a user's Kerberos credentials by use of cifs.upcall(8), 
which peeks into the environment of the process that caused a key to be 
requested, and uses the value of KRB5CCNAME that it finds there. autofs can't 
do something similar because the kernels doesn't make the PID of the requesting 
process available to it.)

BTW, I might have run into a bug while figuring out the above. I noticed that 
changes to [libdefaults]default_ccache_name in krb5.conf weren't taking effect 
even after a reboot! It turns out that pam_sss.so sets KRB5CCNAME during login 
to the value from its cache, rather than from krb5.conf. I ended up using 
ldbedit to remove the ccacheFile  attribute from my user record and logging in 
again, whereupon the attribute was added again with the new expected value.

-- 
Sam Morris <https://robots.org.uk>
___
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] Help with pam_sss_gss.so

2021-04-01 Thread Sam Morris

I have two Debian systems, and using pam_sss_gss.so for sudo works fine on one 
of them, but not the other.

Both have SSSD 2.4.1 installed and are joined to FreeIPA domains.On the system 
where it works, the user is defined in the FreeIPA domain.

On the system where it doesn't work, my user is an AD trust user.

Here's what I get from sssd_pam.log:

(2021-04-01 10:54:52): [pam] [server_common_rotate_logs] (0x0010): Debug level 
changed to 0x07f0
(2021-04-01 10:54:52): [pam] [sbus_issue_request_done] (0x0400): 
sssd.service.rotateLogs: Success
(2021-04-01 10:55:00): [pam] [accept_fd_handler] (0x0400): Client 
[0x55b162023b40][19] connected to privileged pipe!
(2021-04-01 10:55:00): [pam] [sss_cmd_get_version] (0x0200): Received client 
version [3].
(2021-04-01 10:55:00): [pam] [sss_cmd_get_version] (0x0200): Offered version 
[3].
(2021-04-01 10:55:00): [pam] [cache_req_send] (0x0400): CR #6: New request 
'User by name'
(2021-04-01 10:55:00): [pam] [cache_req_process_input] (0x0400): CR #6: Parsing 
input name [sam.mor...@example.net]
(2021-04-01 10:55:00): [pam] [sss_parse_name_for_domains] (0x0200): name 
'sam.mor...@example.net' matched expression for domain 'example.net', user is 
sam.morris
(2021-04-01 10:55:00): [pam] [cache_req_set_name] (0x0400): CR #6: Setting name 
[sam.morris]
(2021-04-01 10:55:00): [pam] [cache_req_select_domains] (0x0400): CR #6: 
Performing a single domain search
(2021-04-01 10:55:00): [pam] [cache_req_search_domains] (0x0400): CR #6: Search 
will check the cache and check the data provider
(2021-04-01 10:55:00): [pam] [cache_req_set_domain] (0x0400): CR #6: Using 
domain [example.net]
(2021-04-01 10:55:00): [pam] [cache_req_prepare_domain_data] (0x0400): CR #6: 
Preparing input data for domain [example.net] rules
(2021-04-01 10:55:00): [pam] [cache_req_search_send] (0x0400): CR #6: Looking 
up sam.mor...@example.net
(2021-04-01 10:55:00): [pam] [cache_req_search_ncache] (0x0400): CR #6: 
Checking negative cache for [sam.mor...@example.net]
(2021-04-01 10:55:00): [pam] [cache_req_search_ncache] (0x0400): CR #6: 
[sam.mor...@example.net] is not present in negative cache
(2021-04-01 10:55:00): [pam] [cache_req_search_cache] (0x0400): CR #6: Looking 
up [sam.mor...@example.net] in cache
(2021-04-01 10:55:00): [pam] [cache_req_search_send] (0x0400): CR #6: Returning 
[sam.mor...@example.net] from cache
(2021-04-01 10:55:00): [pam] [cache_req_search_ncache_filter] (0x0400): CR #6: 
This request type does not support filtering result by negative cache
(2021-04-01 10:55:00): [pam] [cache_req_create_and_add_result] (0x0400): CR #6: 
Found 1 entries in domain example.net
(2021-04-01 10:55:00): [pam] [cache_req_done] (0x0400): CR #6: Finished: Success
(2021-04-01 10:55:00): [pam] [pam_cmd_gssapi_init_done] (0x0400): Trying GSSAPI 
auth: User[sam.mor...@example.net], Domain[example.net], 
UPN[sam.mor...@example.net], Target[h...@myself.ipa.example.net]
(2021-04-01 10:55:00): [pam] [pam_cmd_gssapi_init_done] (0x0400): Returning 
[0]: Success
(2021-04-01 10:55:00): [pam] [client_recv] (0x0400): Invalid data from client, 
closing connection!
(2021-04-01 10:55:00): [pam] [accept_fd_handler] (0x0400): Client 
[0x55b162039780][19] connected to privileged pipe!
(2021-04-01 10:55:00): [pam] [sss_cmd_get_version] (0x0200): Received client 
version [3].
(2021-04-01 10:55:00): [pam] [sss_cmd_get_version] (0x0200): Offered version 
[3].
(2021-04-01 10:55:00): [pam] [client_recv] (0x0400): Invalid data from client, 
closing connection!

There's nothing particularly special about the PAM & SSSD setup; 
/etc/pam.d/sudo starts with "auto sufficient pam_sss_gss.so", and sssd.conf in 
the [pam] sectiion has "pam_gssapi_services = sudo".

I can use strace to see exactly what data is being received by sssd_pam from 
pam_sss_gss.so but I don't know what sensitive data might be within so I don't 
want to post it here. I can provide it privately if it would help.

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9
___
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: Help with pam_sss_gss.so

2021-04-01 Thread Sam Morris

Whoops, I forgot to include the sudo output!

pam_sss_gss: Initializing GSSAPI authentication with SSSD
pam_sss_gss: Switching euid from 0 to 123456789
pam_sss_gss: Trying to establish security context
pam_sss_gss: SSSD User name: sam.mor...@example.net
pam_sss_gss: User domain: example.net
pam_sss_gss: User principal: sam.mor...@example.net
pam_sss_gss: Target name: h...@myself.ipa.example.net
pam_sss_gss: Using ccache: FILE:/run/user/123456789/krb5cc
pam_sss_gss: Acquiring credentials for principal [sam.mor...@example.net]
pam_sss_gss: Communication error [3, 32]: Error in service module; Broken pipe
pam_sss_gss: Switching euid from 123456789 to 0
pam_sss_gss: System error [32]: Broken pipe
[sudo] password for sam.mor...@example.net: ^C

If I run 'klist' at this point, I can see that I've picked up tickets for 
krb5tgt/ipa.example@example.net and 
host/myself.ipa.example@ipa.example.net; so I think the PAM module is 
working, but sssd_pam doesn't like what it sends and closes the connection down.

--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
___
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: Help with pam_sss_gss.so

2021-04-02 Thread Sam Morris

Looking into responder_common.c, the function client_recv logs "Invalid data 
from client, closing connection" if sss_packet_recv returned EINVAL.

Looking into sss_packet_recv, EINVAL is returned if the packet is too large.

Decoding the packet, the first four bytes are the packet length which is 1905; 
the second four are the command type which is 0xfb or SSS_GSSAPI_SEC_CTX. After 
the eight status/reserved bytes are the first 1520 bytes of the packet body. 
The rest of the packet body is never read because after the first recvfrom call 
(into a buffer of 1536 bytes), the connection is closed.

I can see the definition of SSS_PACKET_MAX_RECV_SIZE is 1024. And I can see 
some code in sss_packet_recv that handles two types of packet known to be 
larger (SSS_NSS_GETNAMEBYCERT and SSS_NSS_GETLISTBYCERT, which are allowed to 
be up to SSS_CERT_PACKET_MAX_RECV_SIZE bytes or 10240 bytes long).

So maybe the SSS_GSSAPI_SEC_CTX command needs similar handling of longer 
packets so that it can deal with large kerberos tickets (which Windows users 
will have if they are in lots of groups; a quick Google suggests the PAC may 
grow up to 48 KiB as of Windows Server 2012).

--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
___
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: Help with pam_sss_gss.so

2021-04-06 Thread Sam Morris

Done - https://github.com/SSSD/sssd/issues/5568

Thanks

--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
___
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: Help with pam_sss_gss.so

2021-04-06 Thread Sam Morris

Thanks Pawel, I'll mail the extra logs to you.

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
___
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 performance on large domains

2022-02-03 Thread Sam Morris

I want to get some links to the relevant bugs into this old thread for the 
benefit of anyone finding this thread in the archives...

>> Currently if I do not set "ignore_group_members = True" in sssd.conf,
>> logins can take upwards of 6 minutes and "sssd_be" will max the CPU for
>> up to 20 minutes after logon, which makes it a non-starter. The reason
>> I want to allow group members to be seen is that I want certain domain
>> groups to be able to perform elevated actions using polkit. If I ignore
>> group members, polkit reports that the group is empty and so no one can
>> elevate in the graphical environment.

> I would say here polkit could be improved in addition to sssd. If polkit
> is calling getgr* to find if a user is a member of a certain group it's
> neither going to be precise nor will that work on large environments.
> 
> Did you ask on a polkit list why it's evaluating membership in a group
> with getgr*?

I think Polkit does this so that it can provide the authentication agent with a 
list of users for the user to choose from.

There's this on sssd-devel: 
https://lists.freedesktop.org/archives/polkit-devel/2016-November/000514.html 
and this in Red Hat's Bugzilla: 
https://bugzilla.redhat.com/show_bug.cgi?id=1214026

And there's this Polkit issue: 
https://gitlab.freedesktop.org/polkit/polkit/-/issues/24

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9
___
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] SSH with KbdInteractiveAuthentication - pam_sssd activates wrong credentials cache on login

2022-09-28 Thread Sam Morris

Posting this here before I file a bug because there are a few similar
bugs which have been closed, and so I don't know if I'm seeing one of
them or whether this is a new one.

On the server, before I SSH in, my credentials cache collection looks
like this:

$ printenv KRB5CCNAME
KCM:

$ klist -l
Principal name  Cache name
--  --
u...@example.comKCM:1011:48623 (Expired)
u...@example.comKCM:1011:1518 (Expired)
u...@example.comKCM:1011:12525 (Expired)
u...@example.comKCM:1011:95695 (Expired)
u...@example.comKCM:1011:19607 (Expired)
u...@example.comKCM:1011:25261 (Expired)

$ klist
Ticket cache: KCM:1011:95695
Default principal: u...@example.com

Valid starting ExpiresService principal
06/22/22 00:03:52  06/23/22 00:01:49  krbtgt/example@example.com

The TGT in the primary credentials cache is an old one that expired a
few days ago.

Now I SSH into the server, using keyboard-interactive authentication, so
sshd calls into pam_sss to authenticate me with Kerberos.

$ ssh -v -l user server.example.com
debug1: Next authentication method: keyboard-interactive
(u...@server.example.com) First Factor: 
(u...@server.example.com) Second Factor: 
Authenticated to server.example.com (via proxy) using 
"keyboard-interactive".

$ klist
Ticket cache: KCM:1011:48623
Default principal: u...@example.com

Valid starting ExpiresService principal
05/24/22 23:39:09  05/25/22 23:16:16  krbtgt/example@example.com
05/25/22 19:31:42  05/25/22 23:16:16  HTTP/server.example@example.com

The primary credential cache has been changed to a different cache, that
contains an old, expired ticket. So the I can't use my TGT to access
network services.

If I then list the contents of the original primary credential cache:

$ klist -c KCM:1011:95695
Ticket cache: KCM:1011:95695
Default principal: u...@example.com

Valid starting ExpiresService principal
09/28/22 09:37:09  09/29/22 09:36:36  krbtgt/example@example.com

SSSD put the new TGT into the former primary credential cache, and then
changed the primary credential cache to one of the other caches within
the collection.

I expected that, regardless of whether the new TGT goes into a new
credential cache or an existing one, the destination credential cache is
set as the primary so that it can be used by the user.

In particular this looks like
<https://github.com/SSSD/sssd/issues/4988>, but a comment says that that
has been fixed in RHEL 8 some time ago, nonetheless I'm seeing this
problem on both RHEL 9.0 (sssd-common-2.6.2-4.el9_0.1.x86_64) and RHEL
8.6 (sssd-common-2.6.2-4.el8_6.1.x86_64).

The workaround is to identify the credential cache that contains
non-expired credentials and then make it the primary:

$ klist -l
Principal name  Cache name
--  --
u...@example.comKCM:1011:48623 (Expired)
u...@example.comKCM:1011:1518 (Expired)
u...@example.comKCM:1011:12525 (Expired)
u...@example.comKCM:1011:19607 (Expired)
u...@example.comKCM:1011:95695

$ kswitch -c KCM:1011:95695

If I perform the same test but using gssapi-with-mic authentication in
combination with GSSAPIDelegateCredentials, then I see that the TGT is
stored in a new credentials cache, which is then set as the primary,
e.g. everything works!

I also think that sssd should be cleaning up these old credential
caches. AFAIK, there's no perfect forward secrecy with Kerberos, so can
these old tickets can be used to decrypt captured network traffic?

Regards,

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9
___
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: Does sssd support direct integration to AzureAD?

2023-01-09 Thread Sam Morris


On 09/01/2023 15:38, Spike White wrote:

Sumit,

Thanks for answer.

MS claims that adcli + sssd allows you to join an Azure AD domain services.

https://learn.microsoft.com/en-us/azure/active-directory-domain-services/join-rhel-linux-vm
 
<https://learn.microsoft.com/en-us/azure/active-directory-domain-services/join-rhel-linux-vm>


It looks like that's for Azure AD DS - not 'pure' Azure AD.

(Azure AD DS is like AD DS but Microsoft host the DCs for you, so as far 
as your Linux system is concerned it's like "direct integration" with AD 
DS).


--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9
___
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: not getting cached ticket from PuTTY login

2023-03-27 Thread Sam Morris


On 26/03/2023 22:31, Spike White wrote:
We use GSSAPI instead of  GSS-SPNEGO for ssh SSO, but it should work the 
same.  This does not really involve sssd at all (for the 
authentication).  What happens is that your ssh daemon is 
Kerberos-aware.  So when it is presented with a Kerberos ticket, the ssh 
daemon contacts the Kerberos server (AD DC in our case) to verify the 
ticket.  If authenticated, it allows login.  That is, it bypasses PAM 
for the 'authentication' phase.  It still consults PAM stack for the 
'account' and 'session' phases however,


Because the sshd service in this situation does not call PAM stack for 
the authentication phase, it does not consult pam_sss during the 
authentication phase.   For your account phase and session phase, it 
will consult pam_sss, but that doesn't involve kerberos.


Have you enabled Connection -> SSH -> Auth -> GSSAPI -> Allow GSSAPI 
credential delegation?


--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9
___
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: not getting cached ticket from PuTTY login

2023-03-27 Thread Sam Morris


On 27/03/2023 12:53, Pieter Voet wrote:

Hi Sam,
  > Have you enabled Connection -> SSH -> Auth -> GSSAPI -> Allow GSSAPI
credential delegation?
yes I did.  That did not solve the issue, but since this is on a corporate AD 
domain, I do not have the permission to
check if the Windows laptop has 'Trust this computer for delegation to any 
service (Kerberos only)'  permission...


I don't think that the computer you're SSHing from will affect whether 
delegation is possible. I think the TGT has to have the 'forwardable' 
flag on it?


--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9
___
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: best practice, using machine-account keytab for service SPNs

2023-07-31 Thread Sam Morris

Not an AD expert so perhaps someone else can speak up if I'm getting 
anything wrong...


AD doesn't have a first class object for representing services. Kerberos 
principals are either associated with a computer account or a user account.


It's my understanding that all the Kerberos keys for the SPNs on an 
account are equivalent, i.e., they all let you authenticate as the 
computer account. So even if you separate out the keys into separate 
keytab files per-service, they can all authenticate to AD as the same 
computer account.


AD's solution to this was introduced with Windows Server 2008 R2 in the 
form of "managed service accounts". This is where AD manages a 
service-specific user account and its Kerberos keys, rotating them every 
30 days. The account is linked to a computer account which is able to 
retrieve the account's credentials* and, e.g., put them into a keytab 
for another process to use. If the managed service account's key is 
compromised then the attacker can't authenticate as the computer, only 
the separated service account.


(* Not terribly sure about this as the technical documentation is so 
scant, but I see references to a "Key Distribution Service" (KDS) which 
implies that the computer account is retrieving the MSA's keys from AD 
domain controllers. But it's possible that the KDS is only used for the 
enhanced "group managed service accounts" facility introduced later on, 
which lets a managed service account be linked to a security group of 
computers, all of which can retrieve the managed service acount 
credentials.)


Whether SSSD is able to make use of this this, I don't know. There are 
some docs at 
 
but they're written from the perspective of a host that hasn't been 
joined to the domain with 'realm join'. If the host has been joined then 
I don't know how you'd go about configuring SSSD to retrieve the 
credentials and store them in a separate keytab file.


Sam

25 Jul 2023 15:08:36 Stefan Bauer :

   Spike,

   thank you again. I'm aware of the link James supplied and i already
   tested it successfully. As I'm doing some research, i just wanted to
   have a second/third opinion on how other admins handle the
   keytab/rotation problem.
   Specifically if it is bad practice to have many SPNs on a single
   host-object in Active-Directory :)

   So it looks like i either have to create unique host/user/objects in
   AD and use individual keytab-files for each service, or do the
   separation in software with gssproxy.

   Stefan

   Am Di., 25. Juli 2023 um 15:54 Uhr schrieb Spike White
   :

   Stefan,

From what I'm reading, it looks like James supplied the
   answer.  gssproxy.  This URL:
   gssproxy/docs/Apache.md at main · gssapi/gssproxy · GitHub
   

   seems to demonstrate how to implement this for Apache webserver.

   Spike

   On Tue, Jul 25, 2023 at 12:50 AM Stefan Bauer
wrote:

   Thank you Spike and James for your reply. That was quite
   helpful.
   Yes i currently do have a single host principal in
   Active-Directory, that has numerous servicePrincipalNames:
   HOST/...
   HTTP/
   SQL/...

   for al services, running on this specific host.

   So it can not be separated as the only credential for that
   host is the machine account itself. Correct?

   Is it bad practice to have additional SPNs on the host
   principal?

   How do you associate and rotate your keytabs for services?

   Thank you.

   Stefan



   Am Mo., 24. Juli 2023 um 23:14 Uhr schrieb Spike White
   :

   I know on a former commercial product I used the monthly
   machine account credential renewal had a "hook"
   parameter where you could specify an executable script
   to be called.  It was designed to work with Samba, so
   that you could write the samba keytab file without Samba
   needing to access the /etc/krb5.keytab file.

   Possibly sssd has such a post-rotate hook parameter as
   well.

   That worked great for creating a Samba-viewable
   credentials.

   However, it sounds like you're defining SPNs as
   alternate names for the host principal.  I don't see how
   you could write a HTTP.keytab file or so with entries
   for HTTP/@  without embedding the
   credentials for the host principal (under the HTTP/ SPN
   of course).

   Spike

   On Thu, Jul 20, 2023 at 7:38

[SSSD-users] Re: best practice, using machine-account keytab for service SPNs

2023-08-08 Thread Sam Morris


I found a better explanation of gMASs and MSAs here:

https://syfuhs.net/how-managed-service-accounts-in-active-directory-work

(I'm still not sure if the KDS key is used to derive the keys for 
regular MSAs or just gMSAs. And if not, then how key retrieval works for 
MSAs.)


--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9
___
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: Is there anything in the sssd RHEL server OS settings that performs LDAP binds or connections to AD every 30 mins?

2023-10-06 Thread Sam Morris


On 04/10/2023 17:02, Spike White wrote:
We see in other places in this McAfee script that they run this command 
using 'su' instead of 'sudo'.


su -s /bin/sh -c "LD_LIBRARY_PATH=...  ${PROGROOT}/bin/macmnsvc
status" mfe


Running this command via 'su' instead of 'sudo' would not trigger this 
thundering herd.  (We have verified that.)  Alternatively, randomizing 
their healthcheck execution times would avoid this thundering herd problem.


Anyway, it's McAfee's problem to fix now.  We'll report it and I'm sure 
they'll figure out a solution.


If they are root and want to drop privileges then they would be better 
served by runuser or setpriv. But as you point out even su is better 
than sudo here.


--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9
___
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: reliability of mounting shares while login

2023-10-20 Thread Sam Morris


On 19/10/2023 21:47, Johannes Maier wrote:

Hi @all,

I have some problems when using pam_mount.conf.xml to mount shares via kerberos 
(and also for ntlm) regarding reliability of the mount. I have tested the issue 
with 2 different environments. My environments are: 2 Microsoft Domain 
Controllers + a separate fileserver and Ubuntu 18.04 or 22.04 as clients. My 
other tested environment is one Microsoft Server 2019 (as domain controller and 
fileserver) + Ubuntu 22.04 as client.
The login with my configuration works all the time reliably, but sometimes the 
shares are not getting mounted. I have read a ton of documentation, but can not 
figure out where the problem really is.


You might have better luck with a regular mount entry in /etc/fstab but 
with the x-systemd.automount option, which will cause the mount to be 
deferred to when it's first accesssed. That way a temporary problem 
won't permanently prevent the mount from occurring.


Alternatively, use good old ma; both ways use the same underlying 
autofs(5) mechanism.


--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9
___
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 credential cache for offline authentication

2024-07-03 Thread Sam Morris


On 02/07/2024 12:02, seojeong kim wrote:

/var/lib/sss/db/

I try to use SSSD offline authentication.
under /var/lib/sss/db/
cache_mydomain.ldb
ccache_mydomain.ldb
config.ldb
fast_ccache_mydomain.ldb
sssd.ldb
timestamps_mydomain.ldb


SSSD offline authentication works with the cached credential and credential 
will be stored after the  last successful login.
How can I  check if SSSD credential cached properly after the successful login?
Which file should I check ?


List users in the cache with:

# ldbsearch -H /var/lib/sss/db/cache_mydomain.ldb -s one -b 
cn=users,cn=mydomain,cn=sysdb dn


View a user's cached password:

# ldbsearch -H /var/lib/sss/db/cache_mydomain.ldb -s base -b 
name=user@mydomain,cn=users,cn=mydomain,cn=sysdb cachedPassword


--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

--
___
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] Stability/intended purpose of ccacheFile user attribute

[SSSD-users] Help with pam_sss_gss.so

[SSSD-users] Re: Help with pam_sss_gss.so

[SSSD-users] Re: Help with pam_sss_gss.so

[SSSD-users] Re: Help with pam_sss_gss.so

[SSSD-users] Re: Help with pam_sss_gss.so

[SSSD-users] Re: sssd performance on large domains

[SSSD-users] SSH with KbdInteractiveAuthentication - pam_sssd activates wrong credentials cache on login

[SSSD-users] Re: Does sssd support direct integration to AzureAD?

[SSSD-users] Re: not getting cached ticket from PuTTY login

[SSSD-users] Re: not getting cached ticket from PuTTY login

[SSSD-users] Re: best practice, using machine-account keytab for service SPNs

[SSSD-users] Re: best practice, using machine-account keytab for service SPNs

[SSSD-users] Re: Is there anything in the sssd RHEL server OS settings that performs LDAP binds or connections to AD every 30 mins?

[SSSD-users] Re: reliability of mounting shares while login

[SSSD-users]Re: SSSD credential cache for offline authentication

16 matches

Site Navigation

Mail list logo

Footer information