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
BUILD.txt for 1.10.0
by steve
Hi everyone.
A big thanks for the 1.10.0 release. We have been in production 24/7
with 6 clients on AD since Thursday without issues. The highlight for us
is the dyndns updates. It has been worth every second in the lab.
The only minor problem we had was with the instructions. We had to refer
to the beta BUILD.txt to get it built with:
autoreconf -i -f && ./configure && make
The link to:
https://fedorahosted.org/sssd/wiki/DevelTutorials
is confusing. We had no idea how to get:
reconfig
chmake
sssinstall
I realise that you guys work for Red Hat but would it be possible to
include something for inexperienced users like ourselves in BUILD.txt?
sssd can be built on Fedora with the following dependencies:
gettext gettext-devel libtool pcre-devel c-ares-devel \
python-devel popt-devel doxygen bind-utils libnl3-devel \
samba-devel glib2-devel dbus-devel libxslt docbook-style-xsl \
nspr-devel libxml2 \
libtevent libtevent-devel libtalloc libtalloc-devel \
libtdb libtdb-devel libldb libldb-devel \
libselinux-devel libsemanage-devel \
nss-devel pam-devel openldap-devel krb5-devel \
check-devel libcmocka-devel \
libcollection-devel libdhash-devel libini_config-devel \
libpath_utils-devel libref_array-devel
then a:
reconfig && chmake
from the source folder.
It can be then installed by:
sudo sssinstall
To get started with other distributions try:
autoreconf -i -f && ./configure && make
sudo make install
This will install sssd under /usr/local
On a 32bit system, copy /usr/lib/libnss* to /lib and place your
sssd.conf at /usr/local/etc/sssd
Cheers,
Steve
10 years, 10 months
Announcing SSSD 1.11 beta 1
by Jakub Hrozek
=== SSSD 1.11 beta 1 ===
The SSSD team is proud to announce the first beta release of version 1.11
of the System Security Services Daemon.
This pre-release does not bring any changes visible to the end-user. It
is intended to be part of the development of FreeIPA 3.3 and its focus of
supporting legacy (non-SSSD) clients in a setup where IPA server established
a trust relationship with an Active Directory clients.
The second beta will be released on July 17th with the final release
coming up before the end of July.
As always, the source is available from https://fedorahosted.org/sssd.
== Feedback ==
Please provide comments, bugs and other feedback via the sssd-devel or
sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
== Highlights ==
* The handling of ID ranges in the provides has been changed to use a
plugin interface where each provider can use a different plugin and have
a different behaviour
* The libsss_idmap library has been enhanced in several ways such as
handling "external mappings" or supporting base RIDs other than 0
* The assumption that subdomain users always have a primary
user-private-group (UPG) has been removed
* If the SSSD is running on the IPA server, it is able to perform lookups
for trusted users directly against the AD server using the AD provider
lookups
== Tickets Fixed ==
https://fedorahosted.org/sssd/ticket/1938
[RFE] Add a new call to libsss_idmap to add a new mapping where the first RID is not 0
https://fedorahosted.org/sssd/ticket/1960
[RFE] Add range type for ID mapping in AD to libsss_idmap
https://fedorahosted.org/sssd/ticket/1961
[RFE] Add plugin to LDAP provider to find new ranges
https://fedorahosted.org/sssd/ticket/1962
[RFE] Integrate AD provider lookup code into IPA subdomain user lookup
https://fedorahosted.org/sssd/ticket/1979
[RFE] Add an optional unique range identifier
https://fedorahosted.org/sssd/ticket/1993
[RFE] Add a new option to denote server mode
== Detailed Changelog ==
Jakub Hrozek (11):
* Updating the version for the 1.10.1 release
* Bump version to track 1.11 development
* IPA: Add a server mode option
* LDAP: Add utility function sdap_copy_map
* AD: decouple ad_id_ctx initialization
* AD: initialize failover with custom realm, domain and failover service
* IPA: Initialize server mode ctx if server mode is on
* AD: Move storing sdap_domain for subdomain to generic LDAP code
* IPA: Create and remove AD id_ctx for subdomains discovered in server mode
* IPA: Look up AD users directly if IPA server mode is on
* Updating translations for the 1.11 beta1 release
Sumit Bose (18):
* idmap: allow first RID to be set
* idmap: add optional unique range id
* idmap: add option to indicate external_mapping
* idmap: allow NULL domain sid for external mappings
* idmap: add calls to check if ID mapping conforms to ranges
* idmap: add sss_idmap_domain_has_algorithmic_mapping
* Add cmocka based tests for libsss_idmap
* Add now options ldap_min_id and ldap_max_id
* SDAP IDMAP: Add configured domain to idmap context
* Allow different methods to find new domains for idmapping
* Add sdap_idmap_domain_has_algorithmic_mapping()
* Replace SDAP_ID_MAPPING checks with sdap_idmap_domain_has_algorithmic_mapping
* Add ipa_idmap_init()
* Add support for new ipaRangeType attribute
* Replace new_subdomain() with find_subdomain_by_name()
* IPA: read ranges before subdomains
* Save mpg state for subdomains
* Read mpg state for subdomains from cache
10 years, 10 months
