Re: [SSSD] Unable to resolv netgroup with sssd
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/08/2013 09:27 AM, Mathieu Bouillaguet wrote:
> You're right, we don't need the [LOCAL] section. I removed it. and
> set domains to only the AD domain we use.
>
> Still, I cannot resolv netgroups. When I execute the "getent
> netgroup -s sss Linux.Global" command and I see a fatal error in
> the log of sssd_nss.log :
>
Well, I see the problem. In
[domain/AOP]
...
use_fully_qualified_names = True
But you're not using a fully-qualified name in the lookup. So it can't
send the request to the AOP domain. You've passed a short name
(linux.global instead of linux.global!AOP), so it skips over domains
that require fully-qualified names. In general, fully-qualified names
don't work well with netgroups.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlHaxIEACgkQeiVVYja6o6OiLwCfeAkRmRZHxUmOPmCx3bIKqPyL
KYkAn0jfyaQBM88ASCVuiNYuJZ6P649I
=5kGN
-----END PGP SIGNATURE-----
10 years, 9 months
Unable to resolv netgroup with sssd
by Mathieu Bouillaguet
Hello,
We are trying to get sssd to resolv netgroups. Our goal is to be able to
specify group of hosts in sudo rules. The sudo configuration is held in the
Active Directory DC. The only way to do that in our environment seems to be
by using host netgroups.
We use Red Hat 6.2, the sssd version is 1.5.1.-66.el6.
We have a working configuration with auth_provider=krb5, id_provider=ldap
and access_provider=ldap.
In nsswitch.conf passwd, group and shadow have "files sss" and getent
return the expected information.
For netgroup, I have also put "files sss" but I cannot resolv any netgroup.
When I type : getent netgroup -s sss <NetGroup>
I see the following logs in sssd_nss.log :
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [sbus_dispatch] (9): dbus conn:
6560B0
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [sbus_dispatch] (9): Dispatching.
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [sbus_message_handler] (9): Received
SBUS method [ping]
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [get_client_cred] (9): Client creds:
euid[0] egid[0] pid[18938].
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [accept_fd_handler] (4): Client
connected!
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [sss_cmd_get_version] (5): Received
client version [1].
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [sss_cmd_get_version] (5): Offered
version [1].
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [setnetgrent_send] (4): Requesting
info for netgroup [Linux.Global] from [<ALL>]
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [sss_ncache_check_str] (8): Checking
negative cache for [NCE/NETGR/LOCAL/Linux.Global]
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [lookup_netgr_step] (4): Requesting
info for [Linux.Global@LOCAL]
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [ldb] (9): tevent: Added timed event
"ltdb_callback": 0x65dc80
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [ldb] (9): tevent: Added timed event
"ltdb_timeout": 0x652170
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [ldb] (9): tevent: Destroying timer
event 0x652170 "ltdb_timeout"
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [ldb] (9): tevent: Ending timer
event 0x65dc80 "ltdb_callback"
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [lookup_netgr_step] (2): No matching
domain found for [Linux.Global], fail!
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [nss_cmd_setnetgrent] (0): Fatal
error calling setnetgrent_send
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [client_recv] (5): Client
disconnected!
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [get_client_cred] (9): Client creds:
euid[0] egid[0] pid[18938].
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [accept_fd_handler] (4): Client
connected!
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [sss_cmd_get_version] (5): Received
client version [1].
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [sss_cmd_get_version] (5): Offered
version [1].
(Fri Jul 5 15:48:04 2013) [sssd[nss]] [client_recv] (5): Client
disconnected!
(Fri Jul 5 15:48:14 2013) [sssd[nss]] [sbus_dispatch] (9): dbus conn:
6560B0
(Fri Jul 5 15:48:14 2013) [sssd[nss]] [sbus_dispatch] (9): Dispatching.
(Fri Jul 5 15:48:14 2013) [sssd[nss]] [sbus_message_handler] (9): Received
SBUS method [ping]
(Fri Jul 5 15:48:24 2013) [sssd[nss]] [sbus_dispatch] (9): dbus conn:
6560B0
(Fri Jul 5 15:48:24 2013) [sssd[nss]] [sbus_dispatch] (9): Dispatching.
(Fri Jul 5 15:48:24 2013) [sssd[nss]] [sbus_message_handler] (9): Received
SBUS method [ping]
Notably, I can see that it appears as if sssd cannot find the right domain
to query netgroups.
This is strange since user and group resolv fine and the configuration is
shared for user, groups and netgroup resolving.
The sssd.cofn is attached.
Do you see anything that could break netgroup resolution ?
Thanks in advance
10 years, 9 months
[PATCH] Move sssd_pac binary to the IPA and AD providers
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fedora/RHEL RPMs allow us to provide the *identical* file in two
subpackages without them conflicting. We'll move the sssd_pac
executable into the sssd-ad and sssd-ipa subpackages so that the main
kerberos provider doesn't have dependencies on samba4.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlHS+CUACgkQeiVVYja6o6MUUQCggnT94HfEFvjrxbt+d1+Ei7Cz
Ky0An2yQL8PODVsnZuSJqRNxwN7k7WPQ
=FObH
-----END PGP SIGNATURE-----
10 years, 10 months
[PATCH] BUILD: Use pkg-config to detect cmocka
by Lukas Slebodnik
ehlo,
libcmocka-0.3 was released and package is available in fedore >= 18.
libcmocka-devel contains pkg-config file,
therefore it is better to use pkg-config to detect this library.
Patch is attached.
LS
10 years, 10 months
[PATCHES] Specfile updates (one urgent)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Patch 0001: Move pre and post scripts to sssd-common
When we switched to making 'sssd' a meta-package, we forgot to move
the upgrade scripts into the sssd-common package. This means that
updates won't work right without the 'sssd' package and that removing
the meta-package (i.e. to trim down requirements) will remove SSSD
from the services lists.
Patch 0002: There are no longer any Fedora systems with a SYSV SSSD on
them, so we no longer need the upgrade logic in the specfile.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlHRsvkACgkQeiVVYja6o6PbTACdFxeHoEpsJO2VJk5QtXQY4PCG
XugAniofsJd2AkNzKKZY/IM3qvhh5Q8A
=umJx
-----END PGP SIGNATURE-----
10 years, 10 months
question on private groups with AD domain
by Greg Lehmann
Hi All,
Red Hat tend to configure users by default with uid=gid when a user is created. This means there is a corresponding private group with the same name as the user. It is not possible to do this in AD without a bit of trickery. Is there any way to configure sssd so it tries to map the gid through the user uid-name mapping if no match is found on the gid to group name mapping? If not can I request this feature be added please?
TIA,
Greg Lehmann
Cluster Services, ASC
CSIRO Information Management and Technology
Phone: +61 7 3327 4137 | Fax: +61 1 3327 4455
Greg.Lehmann(a)csiro.au | www.csiro.au
Address: 1 Technology Court, Pullenvale, QLD 4069
PLEASE NOTE
The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.
Please consider the environment before printing this email.
10 years, 10 months
Access denied by pam_sss(sshd:account)
by Mathieu Bouillaguet
Hello,
We are trying to setup Kerberos authentication for our linux VMs on an
Active Directory.
We use Red Hat 6.2, the sssd version is 1.5.1.-66.el6.
getent retrieve the domain users and groups.
If I try to ssh into the VM I am disconnected with "pam_sss(sshd:account)
access denied for user". The pam authentication module succeed as seen in
the log but the account management module reject me each time.
If I comment the line "account [default=bad success=ok user_unknown=ignore]
pam_sss.so" in the /etc/pam.d/password-auth fileI can login via ssh. If I
comment it in the /etc/pam.d/system-auth file I can log in locally.
I can't find the reason why this pam_sss account management module rejects
me. I didn't find anything interesting in the logs. I looked in the
/var/log/secure, /var/log/sssd/sssd_pam.log /var/log/sssd/sssd_*domain*.log,
I even searched in the source code but to no avail.
In the /var/log/secure file when I try a local login, I get
login: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0
euid=0 tty=tty1 ruser= rhost= user=yiqevm@AOP
login: pam_sss(login:auth): authentication success; logname=LOGIN uid=0
euid=0 tty=tty1 ruser= rhost= user=yiqevm@AOP
login: pam_sss(login:account): Access denied for user yiqevm@AOP: 6
(Permission denied)
login: Permission denied
And when I try to ssh :
sshd[8685]: pam_unix(sshd:auth): authentication failure; logname= uid=0
euid=0 tty=ssh ruser= rhost=172.34.155.223 user=yiqevm@aop
sshd[8685]: pam_sss(sshd:auth): authentication success; logname= uid=0
euid=0 tty=ssh ruser= rhost=172.34.155.223 user=yiqevm@aop
sshd[8685]: pam_sss(sshd:account): Access denied for user yiqevm@aop: 6
(Permission denied)
sshd[8685]: Failed password for yiqevm@aop from 172.34.155.223 port 51922
ssh2
sshd[8688]: fatal: Access denied for user yiqevm@aop by PAM account
configuration
In the sssd_domain.log I get :
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): command:
PAM_AUTHENTICATE
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): domain: AOP
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): user:
yiqevm
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): service:
sshd
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): tty: ssh
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): ruser:
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): rhost:
localhost
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): authtok
type: 1
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): authtok
size: 12
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): newauthtok
type: 0
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): newauthtok
size: 0
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): priv: 0
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): cli_pid:
8734
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [check_if_ccache_file_is_used]
(5): User [777778] is not active
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [check_for_valid_tgt] (3): TGT
is valid.
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [fo_resolve_service_send] (4):
Trying to resolve service 'KERBEROS'
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [be_resolve_server_done] (4):
Found address for server auth1.aop.chorus.aife: [172.34.154.86] TTL 3443
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [fo_resolve_service_send] (4):
Trying to resolve service 'KPASSWD'
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [be_resolve_server_done] (4):
Found address for server auth1.aop.chorus.aife: [172.34.154.86] TTL 3443
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [write_pipe_handler] (6): All
data has been sent!
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [read_pipe_handler] (6): EOF
received, client finished
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [fo_set_port_status] (4):
Marking port 0 of server 'auth1.aop.chorus.aife' as 'working'
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [set_server_common_status] (4):
Marking server 'auth1.aop.chorus.aife' as 'working'
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [fo_set_port_status] (4):
Marking port 88 of server 'auth1.aop.chorus.aife' as 'working'
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [set_server_common_status] (4):
Marking server 'auth1.aop.chorus.aife' as 'working'
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [be_pam_handler_callback] (4):
Backend returned: (0, 0, <NULL>) [Success]
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [be_pam_handler_callback] (4):
Sending result [0][AOP]
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [be_pam_handler_callback] (4):
Sent result [0][AOP]
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [child_sig_handler] (4): child
[8738] finished successfully.
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [be_pam_handler] (4): Got
request with the following data
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): command:
PAM_ACCT_MGMT
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): domain: AOP
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): user:
yiqevm
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): service:
sshd
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): tty: ssh
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): ruser:
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): rhost:
localhost
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): authtok
type: 0
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): authtok
size: 0
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): newauthtok
type: 0
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): newauthtok
size: 0
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): priv: 0
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [pam_print_data] (4): cli_pid:
8734
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [write_pipe_handler] (6): All
data has been sent!
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [read_pipe_handler] (6): EOF
received, client finished
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [be_pam_handler_callback] (4):
Backend returned: (0, 6, <NULL>) [Success]
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [be_pam_handler_callback] (4):
Sending result [6][AOP]
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [be_pam_handler_callback] (4):
Sent result [6][AOP]
(Wed Jun 26 12:27:39 2013) [sssd[be[AOP]]] [child_sig_handler] (4): child
[8739] finished successfully.
Any help, would be appreciated.
Thanks
10 years, 10 months