sudo rules do not get ALL run-as-user
by Dominik George
[ Not subscribed, please Cc in replies. ]
Hi,
we are usign sssd 1.15.0 on Debian stretch, for everything including sudo.
The following LDAP entry…
dn: cn=%supraadmin,ou=SUDOers,dc=teckids,dc=org
objectClass: top
objectClass: sudoRole
cn: %supraadmin
description: Allow everything for supraadmins
sudoUser: %supraadmin
sudoCommand: ALL
sudoHost: ALL
…keeps rendering as this insudo…
User nik may run the following commands on ticdesk:
(root) ALL
…even if I add sudoRunAsUser: ALL explicitly.
I already tried wiping the sss cache, with no success.
Any hints on why this happens:
Cheers,
Nik
--
Dominik George (1. Vorstandsvorsitzender, pädagogischer Leiter)
Teckids e.V. - Erkunden, Entdecken, Erfinden.
https://www.teckids.org/
5 years, 11 months
does sssd support using a Microsoft read-only Domain Controller (RODC)?
by James Ralston
Has anyone figured out how to make sssd utilize a Microsoft read-only
Domain Controller (RODC)?
The host we want to join to AD is already behind the RODC. So, we are
trying to "join" the host to the RODC by pre-creating a computer
account object in AD (via a RWDC), then exporting a Kerberos keytab
file to install on the client host.
On the client host, in the /etc/krb5.conf file, we have overridden the
"kdc" setting for our domain, pointing it to the RODC. In
/etc/sssd/sssd.conf, we have set "ad_server" for our domain, pointing
it to the RODC. Using the exported keytab file, we can run "kinit -k"
successfully.
But no matter how we create the computer account object, or how we
export the Kerberos keytab, sssd cannot use the resulting keytab file
to authenticate to the RODC: when sssd sends the AS-REQ, the RODC
always replies with KRB5KDC_ERR_PREAUTH_FAILED.
I'm beginning to suspect that sssd just doesn't work with RODCs: if
"kinit -k" can successfully authenticate and acquire a service
principal using the keytab file we exported to the client from the
RWDC, then why can't sssd successfully use it?
Can anyone confirm that you have sssd successfully speaking to a
Microsoft RODC?
If so, did you join the client host to a RWDC and then move it behind
the RODC? Or did you pre-create the machine account on the RWDC and
export the Kerberos keytab to the client? If the latter, do you have
the exact net/admod/ktpass commands you used to pre-create the
computer account and export the keytab in a way that is compatible
with sssd?
Thanks in advance for any pointers or advice!
5 years, 11 months
Existing UID ranges
by John Hearns
Hello all. I am currently working on a new project to configure sssd
authentication, for Ubuntu clients.
And hello to Lachlan Musicman - did not expect to see you here!
I think this question must be asked many times. So forgive me.
We have an existing set of Unix usernames/uids which are pushed out onto
the client workstations vi a configuration management system. Ie there are
local /etc/passwd files which are updated when new users joint he company.
the uid range is 1000 to 3000
If we start to use sssd with AD authentication and the AD RID mapping, then
different UIDs will be reported.
We do not wish to use the Posix attributes - the whole point is to reduce
the manual steps needed when new accounts are created.
So my questions are:
a) is there any way to map AD RID style UIDs to existing UIDs (I have
tried to search for this)
b) other orgnisations have faced this. Is the only answer a script to
chown each users files if they are transitioned over to AD?
Also a question about pam_mkhomedir I have used this successfully in the
past, on a BeeGFS filesystem where all the clients have read/write access.
If the workstation is an NFS client, then creating a new home directory for
a user should not be possible, given that root squash is configured on the
NFS share.
Is there a smart way to get pam_mkhomedir to work on an NFS client system?
Or perhaps the user needs to log into the NFS server system one time only
(assuming logins are encouraged directly to servers like that anyway)
Thanks for any thoughts and insights.
John Hearns
5 years, 11 months
Automatic parameter update in /etc/sssd/sssd.conf
by TomK
Hey All,
Is there a way to add or modify parameters in sssd.conf without having
to grep, sed or awk things to get the same thing done?
I know Ansible / Salt are one way but wondering if there are any IPA /
SSSD specific commands to do the same.
--
Cheers,
Tom K.
-------------------------------------------------------------------------------------
Living on earth is expensive, but it includes a free trip around the sun.
5 years, 11 months
unexpected owner for credentials
by Charles Hedrick
I’m trying to support an odd configuration.
We have an IPA system, which is used in the normal way for systems run by staff. But we have hundreds of systems run by faculty and grad students. I’d like to encourage them to integrate with our system. However their usernames and UIDs don’t typically match ours. I don’t think there’s much I can do about usernames. But I’d at least like to survive differing UIDs. Kerberos and even NFS V4 don’t care about UIDs.
So I set up sssd pointing to IPA, with access_provider = deny (meaning only people accepted by pam_unix can login), and nsswitch.conf having “files sss." If a user logins in with the Kerberos password they’re logged in correctly, but they can’t access their own Kerberos credentials.
Their logged in UID is the one in /etc/passwd, because login correctly obeys nsswitch. But their Kerberos credentials are for the UID in IPA.
I can change id_provider to proxy/files. But then the sss nsswitch map doesn’t work. I need to get groups from IPA in order to interpret groups on our Netapp. I’d like to get users from IPA when there isn’t an entry in /etc/passwd, so that ls -l on the Netapp can interpret user names.
So what I’d like is that when sssd creates Kerberos credentials, it uses the same user that login is going to use, i.e. that it obeys nsswitch. Is this a reasonable expectation?
Going further, I’d like a way to do username mapping that will work with both sssd and Kerberos. One approach would be to pay attention to the username map in /etc/krb5.conf or idmapd.conf, since I’d have to put the mapping in both (I think).
5 years, 11 months
Config for joining AD forest and Kerberos cross-domain authentication
by Bastian Rosner
Hi,
we are looking for a detailed configuration example to join an AD forest
with working Kerberos authentication.
Our AD infrastructure consists of a single forest with multiple
(sub-)domains in two-way trust. No FreeIPA, just Windows 2012 AD servers
and SSSD clients using version 1.11 and 1.15 on Debian.
We can successfully join with sssd-ad using the "net ads join" command
and users from the same domain can authenticate using a Kerberos ticket
or password. Also mounting CIFS shares via pam-mount works fine in the
same domain.
Unfortunately, users from other domains can't use their Kerberos ticket,
only password works. These users are specifying their domain on login.
Surprisingly, once logged in after authenticating with a password,
foreign-domain users are able to issue a Kerberos ticket with kinit if
they specify username@FQDN (with capital letters). Also lookup up group
membership of users from another domain works fine, so presumably the
LDAP part is working correctly.
This is our current config, are we missing something in order to get
Kerberos cross-domain authentication working?
$ cat /etc/sssd/sssd.conf
[sssd]
domains = sub1.example.com
services = nss, pam, pac
config_file_version = 2
[nss]
filter_groups = root
filter_users = root
[pam]
[domain/sub1.example.com]
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
cache_credentials = true
ldap_referrals = false
ldap_force_upper_case_realm = true
ad_gpo_access_control = disabled
override_homedir = /home/%u
default_shell = /bin/bash
Thanks and kind regards,
Bastian
5 years, 11 months
Re: AD sudo rules have no values for attributes?
by Max DiOrio
I fixed it. Here’s more from the sssd_domain log. A single line revealed the issue. When storing the DevTest rule it said a value is provided more than once. When I looked at the entry in AD, the attribute sudoUser had the same group entered twice. Once as %GS-Technology, once as %gs-technology.
I’m guessing someone was thinking that the group lookup was case sensitive and entered it both ways to rule that out. Ends up breaking the storing of the rules and it seems if one rule fails to be stored, they all are. Not necessarily the best thing to do maybe?
(Thu Apr 5 13:30:44 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sysdb_store_custom] (0x0020): Failed to store custom entry: Attribute or value exists(20)[attribute 'sudoUser': value #5 on 'name=DevTest,cn=sudorules,cn=custom,cn=internal.ieeeglobalspec.com,cn=sysdb' provided more than once]
Thanks!
Max
5 years, 11 months
AD sudo rules have no values for attributes?
by Max DiOrio
I've got a few dozen servers using SSSD to authenticate and retrieve SUDO
rules stored in AD and GPO. Everything works perfectly except for a new
RHEL 6.8 server I brought up. sssd version 1.13.3 on both the working 6.8
and non-working 6.8 server. I literally copied the nsswitch, sssd.conf and
pam.d configs between the two just to make sure I didn't typo anything.
It authenticates fine and I can ssh into it, id account, do genet on the
users and groups without a problem. But sudo fails. Looking at debug
logs, I see it retrieving the 3 sudo rules we have stored in AD, however
it's complaining that there are no sub-attributes in the rules when there
clearly are. I'm guessing this is the source of my issues, but I have no
idea why it's not working only on this one server.
Any thoughts? Thanks!
(Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]]
[sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY]
(Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]]
[sdap_parse_entry] (0x1000): OriginalDN:
[CN=fullaccess,OU=sudoers,DC=internal,DC=ieeeglobalspec,DC=com].
(Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]]
[sdap_parse_range] (0x2000): No sub-attributes for [objectClass]
(Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]]
[sdap_parse_range] (0x2000): No sub-attributes for [cn]
(Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]]
[sdap_parse_range] (0x2000): No sub-attributes for [uSNChanged]
(Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]]
[sdap_parse_range] (0x2000): No sub-attributes for [sudoCommand]
(Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]]
[sdap_parse_range] (0x2000): No sub-attributes for [sudoUser]
(Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]]
[sdap_parse_range] (0x2000): No sub-attributes for [sudoHost]
(Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]]
[sdap_process_result] (0x2000): Trace: sh[0xd42dc0], connected[1],
ops[0xd677a0], ldap[0xd42800]
(Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]]
[sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY]
(Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]]
[sdap_parse_entry] (0x1000): OriginalDN:
[CN=DevTest,OU=sudoers,DC=internal,DC=ieeeglobalspec,DC=com].
(Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]]
[sdap_parse_range] (0x2000): No sub-attributes for [objectClass]
(Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]]
[sdap_parse_range] (0x2000): No sub-attributes for [cn]
(Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]]
[sdap_parse_range] (0x2000): No sub-attributes for [uSNChanged]
(Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]]
[sdap_parse_range] (0x2000): No sub-attributes for [sudoRunAsUser]
(Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]]
[sdap_parse_range] (0x2000): No sub-attributes for [sudoCommand]
(Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]]
[sdap_parse_range] (0x2000): No sub-attributes for [sudoUser]
(Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]]
[sdap_parse_range] (0x2000): No sub-attributes for [sudoHost]
....
(Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=a-mdiorio)(sudoUser=a-mdiorio)(sudoUser=#1002201106)(sudoUser=%Allowed\20RODC\20Password$
Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About
to get sudo rules from cache
(Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(name=defaults)))]
(Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
(0x0400): Returning 0 rules for [<default options>@
internal.ieeeglobalspec.com]
(Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'a-mdiorio' matched without domain, user is a-mdiorio
(Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'a-mdiorio' matched without domain, user is a-mdiorio
(Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
(0x0200): Requesting rules for [a-mdiorio] from [<ALL>]
(Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sss_ncache_check_str] (0x2000):
Checking negative cache for [NCE/USER/internal.ieeeglobalspec.com/a-mdiorio]
(Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_user] (0x0200):
Requesting info about [a-mdiorio(a)internal.ieeeglobalspec.com]
(Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_user] (0x0400):
Returning info for user [a-mdiorio(a)internal.ieeeglobalspec.com]
(Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_rules] (0x0400):
Retrieving rules for [a-mdiorio] from [internal.ieeeglobalspec.com]
(Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=a-mdiorio)(sudoUser=a-mdiorio)(sudoUser=#1002201106)(sudoUser=%Allowed\20RODC\20Password$
(Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About
to get sudo rules from cache
(Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=a-mdiorio)(sudoUser=a-mdiorio)(sudoUser=#1002201106)(sudoUser=%Allowed\20RODC\20Password\20Replication\$
(Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
(0x0400): Returning 0 rules for [a-mdiorio(a)internal.ieeeglobalspec.com]
5 years, 11 months
sssd 1.16.1 wont start, Centos 7.4
by Lachlan Musicman
Using the newly minted SSSD 1.16.1 from COPR, the sssd service doesn't
restart.
( https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-16/)
The journalctl -xe shows:
-- Unit sssd.service has begun starting up.
Mar 29 09:05:55 linuxclient1.unixdev.company.com sssd[1477]: Starting up
Mar 29 09:05:55 linuxclient1.unixdev.company.com systemd[1]: sssd.service:
main process exited, code=exited, status=3/NOTIMPLEMENTED
Mar 29 09:05:55 linuxclient1.unixdev.company.com systemd[1]: Failed to
start System Security Services Daemon.
-- Subject: Unit sssd.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
The /var/log/sssd/sssd.log shows
(Thu Mar 29 09:03:44 2018) [sssd] [server_setup] (0x0400): CONFDB:
/var/lib/sss/db/config.ldb
(Thu Mar 29 09:03:44 2018) [sssd] [_snotify_create] (0x0400): Added a watch
for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 using
function resolv_conf_inotify_cb after delay 1.0
(Thu Mar 29 09:03:44 2018) [sssd] [sss_names_init_from_args] (0x0100):
Using re
[(((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))].
(Thu Mar 29 09:03:44 2018) [sssd] [sss_fqnames_init] (0x0100): Using fq
format [%1$s].
(Thu Mar 29 09:03:44 2018) [sssd] [sysdb_domain_init_internal] (0x0200): DB
File for unixdev.company.com: /var/lib/sss/db/cache_unixdev.company.com.ldb
(Thu Mar 29 09:03:44 2018) [sssd] [sysdb_domain_init_internal] (0x0200):
Timestamp file for unixdev.company.com:
/var/lib/sss/db/timestamps_unixdev.company.com.ldb
(Thu Mar 29 09:03:44 2018) [sssd] [ldb] (0x0400): asq: Unable to register
control with rootdse!
(Thu Mar 29 09:03:44 2018) [sssd] [sbus_new_server] (0x0020):
dbus_server_listen failed! (name=org.freedesktop.DBus.Error.AccessDenied,
message=Failed to bind socket "/var/lib/sss/pipes/private/sbus-monitor":
Permission denied)
(Thu Mar 29 09:05:55 2018) [sssd] [server_setup] (0x0400): CONFDB:
/var/lib/sss/db/config.ldb
(Thu Mar 29 09:05:55 2018) [sssd] [_snotify_create] (0x0400): Added a watch
for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 using
function resolv_conf_inotify_cb after delay 1.0
(Thu Mar 29 09:05:55 2018) [sssd] [sss_names_init_from_args] (0x0100):
Using re
[(((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))].
(Thu Mar 29 09:05:55 2018) [sssd] [sss_fqnames_init] (0x0100): Using fq
format [%1$s].
(Thu Mar 29 09:05:55 2018) [sssd] [sysdb_domain_init_internal] (0x0200): DB
File for unixdev.company.com: /var/lib/sss/db/cache_unixdev.company.com.ldb
(Thu Mar 29 09:05:55 2018) [sssd] [sysdb_domain_init_internal] (0x0200):
Timestamp file for unixdev.company.com:
/var/lib/sss/db/timestamps_unixdev.company.com.ldb
(Thu Mar 29 09:05:55 2018) [sssd] [ldb] (0x0400): asq: Unable to register
control with rootdse!
(Thu Mar 29 09:05:55 2018) [sssd] [sbus_new_server] (0x0020):
dbus_server_listen failed! (name=org.freedesktop.DBus.Error.AccessDenied,
message=Failed to bind socket "/var/lib/sss/pipes/private/sbus-monitor":
Permission denied)
/var/lib/sss/pipes/private shows
drwxr-x---. 2 sssd root 4096 Mar 29 08:50 .
drwxr-xr-x. 3 sssd sssd 71 Mar 29 03:01 ..
srw------- 1 root root 0 Mar 19 09:21 pam
lrwxrwxrwx 1 root root 62 Mar 19 09:20 sbus-dp_unixdev.company.com ->
/var/lib/sss/pipes/private/sbus-dp_unixdev.company.com.758
srw------- 1 root root 0 Sep 18 2017 sbus-dp_unixdev.company.com.732
srw------- 1 root root 0 Dec 28 09:47 sbus-dp_unixdev.company.com.746
It looks like there's some clean up that's not happening? I don't actually
know what sbus_dp files do, but the top result (pointing to .758) doesn't
exist...
How do I fix this?
Cheers
L.
------
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "
*Greg Bloom* @greggish
https://twitter.com/greggish/status/873177525903609857
5 years, 12 months