Hello --
We are running the 14.04.3 LTS 64-bit release as a virtual machine on a Vmware appliance. The goal of the installation is to create a Samba server that utilizes Active Directory authentication. To that end I utilized the following procedure:
http://www.kiloroot.com/add-ubuntu-1...n-credentials/http://www.kiloroot.com/add-ubuntu-14-04-server-or-desktop-to-microsoft-active-directory-domain-login-to-unity-with-domain-credentials/
Afterwards, I referenced the following documentation to confirm that all configuration files had the appropriate entries:
https://help.ubuntu.com/lts/serverguide/sssd-ad.html
The problem is the following: I am unable to log into the server from the console or via SSH using my Active Directory user account. The syntax that I use when doing an SSH connection is the following:
ssh -v -l <username>@<domainname> <fully qualified domain name>
The output that was generated is the following:
OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to <fully qualified domain name> [<ip address>] port 22. debug1: Connection established. debug1: identity file /home/knoppix/.ssh/id_rsa type -1 debug1: identity file /home/knoppix/.ssh/id_rsa-cert type -1 debug1: identity file /home/knoppix/.ssh/id_dsa type -1 debug1: identity file /home/knoppix/.ssh/id_dsa-cert type -1 debug1: identity file /home/knoppix/.ssh/id_ecdsa type -1 debug1: identity file /home/knoppix/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.7 debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.7 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA ec:09:c1:bc:d0:11:f3:8c:45:3f:dd:3a:96:ba:2a:17 debug1: Host '<fully qualified domain name>' is known and matches the ECDSA host key. debug1: Found key in /home/knoppix/.ssh/known_hosts:29 debug1: ssh_ecdsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /home/knoppix/.ssh/id_rsa debug1: Trying private key: /home/knoppix/.ssh/id_dsa debug1: Trying private key: /home/knoppix/.ssh/id_ecdsa debug1: Next authentication method: password <username>@<domainname>@<fully qualified domain name>'s password: Connection closed by <ip address>
I checked the auth.log file, and the following entries were present:
Jun 10 07:10:50 rorecovery1 sshd[7419]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<fqdn> user=<username>@<domainname> Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_winbind(sshd:auth): getting password (0x00000388) Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_winbind(sshd:auth): pam_get_item returned a password Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<fqdn> user=username>@<domainname> Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_sss(sshd:auth): received for user username>@<domainname> 17 (Failure setting user credentials) Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_ldap: could not open secret file /etc/ldap.secret (No such file or directory) Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_ldap: ldap_simple_bind Can't contact LDAP server Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_ldap: reconnecting to LDAP server... Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_ldap: ldap_simple_bind Can't contact LDAP server Jun 10 07:10:53 rorecovery1 sshd[7419]: Failed password for invalid user username>@<domainname>from <ip address> port 49847 ssh2 Jun 10 07:10:55 r
Does anyone have thoughts on this?
Thanks.
On Fri, Jun 10, 2016 at 11:45:43AM -0000, ahkaplan@partners.org wrote:
I checked the auth.log file, and the following entries were present:
Jun 10 07:10:50 rorecovery1 sshd[7419]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<fqdn> user=<username>@<domainname> Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_winbind(sshd:auth): getting password (0x00000388) Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_winbind(sshd:auth): pam_get_item returned a password Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<fqdn> user=username>@<domainname> Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_sss(sshd:auth): received for user username>@<domainname> 17 (Failure setting user credentials) Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_ldap: could not open secret file /etc/ldap.secret (No such file or directory) Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_ldap: ldap_simple_bind Can't contact LDAP server Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_ldap: reconnecting to LDAP server... Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_ldap: ldap_simple_bind Can't contact LDAP server Jun 10 07:10:53 rorecovery1 sshd[7419]: Failed password for invalid user username>@<domainname>from <ip address> port 49847 ssh2 Jun 10 07:10:55 r
Not without logs: https://fedorahosted.org/sssd/wiki/Troubleshooting but my guess is that the client can't reach the server.
Also I would discourage mixing pam_ldap and pam_sss in a single PAM stack.
Hello --
The winbind packages that are installed on the server are the following:
Package Description libnss-winbind 4.3.9+dfsg-0ubuntu0.14.04.3 amd64 Samba nameservice integration plugins libpam-winbind 4.3.9+dfsg-0ubuntu0.14.04.3 amd64 Windows domain authentication integration plugin libwbclient0 4.3.9+dfsg-0ubuntu0.14.04.3 amd64 Samba winbind client library winbind 4.3.9+dfsg-0ubuntu0.14.04.3 amd64 service to resolve user and group information from Windows NT servers
Similarly, the ldap PAM packages are as follows:
Package Description ldap-auth-client 0.5.3 all meta-package for LDAP authentication ldap-auth-config 0.5.3 all Config package for LDAP authentication ldap-utils 2.4.31-1+nmu2ubuntu8.2 amd64 OpenLDAP utilities libldap-2.4-2 2.4.31-1+nmu2ubuntu8.2 amd64 OpenLDAP libraries libldb1 1.1.24-0ubuntu0.14.04.1 amd64 LDAP-like embedded database - shared library libnss-ldap 264-2.2ubuntu4.14.04.1 amd64 NSS module for using LDAP as a naming service libpam-ldap 184-8.5ubuntu3 amd64 Pluggable Authentication Module for LDAP sssd-ldap 1.11.5-1ubuntu3 amd64 System Security Services Daemon -- LDAP back end
Finally, the sssd packages are the following:
Package Description libsss-idmap0 1.11.5-1ubuntu3 amd64 ID mapping library for SSSD sssd 1.11.5-1ubuntu3 amd64 System Security Services Daemon -- metapackage sssd-ad 1.11.5-1ubuntu3 amd64 System Security Services Daemon -- Active Directory back end sssd-ad-common 1.11.5-1ubuntu3 amd64 System Security Services Daemon -- PAC responder sssd-common 1.11.5-1ubuntu3 amd64 System Security Services Daemon -- common files sssd-ipa 1.11.5-1ubuntu3 amd64 System Security Services Daemon -- IPA back end sssd-krb5 1.11.5-1ubuntu3 amd64 System Security Services Daemon -- Kerberos back end sssd-krb5-common 1.11.5-1ubuntu3 amd64 System Security Services Daemon -- Kerberos helpers sssd-ldap 1.11.5-1ubuntu3 amd64 System Security Services Daemon -- LDAP back end sssd-proxy 1.11.5-1ubuntu3 amd64 System Security Services Daemon -- proxy back end sssd-tools 1.11.5-1ubuntu3 amd64 System Security Services Daemon -- tools
Will removing all packages for the first two groups solve this problem?
On Fri, Jun 10, 2016 at 02:09:44PM +0200, Jakub Hrozek wrote:
On Fri, Jun 10, 2016 at 11:45:43AM -0000, ahkaplan@partners.org wrote:
I checked the auth.log file, and the following entries were present:
Jun 10 07:10:50 rorecovery1 sshd[7419]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<fqdn> user=<username>@<domainname> Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_winbind(sshd:auth): getting password (0x00000388) Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_winbind(sshd:auth): pam_get_item returned a password Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<fqdn> user=username>@<domainname> Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_sss(sshd:auth): received for user username>@<domainname> 17 (Failure setting user credentials) Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_ldap: could not open secret file /etc/ldap.secret (No such file or directory) Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_ldap: ldap_simple_bind Can't contact LDAP server Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_ldap: reconnecting to LDAP server... Jun 10 07:10:51 rorecovery1 sshd[7419]: pam_ldap: ldap_simple_bind Can't contact LDAP server Jun 10 07:10:53 rorecovery1 sshd[7419]: Failed password for invalid user username>@<domainname>from <ip address> port 49847 ssh2 Jun 10 07:10:55 r
Not without logs: https://fedorahosted.org/sssd/wiki/Troubleshooting but my guess is that the client can't reach the server.
Also I would discourage mixing pam_ldap and pam_sss in a single PAM stack.
Same is true for pam_winbind and pam_sss if both should handled the same AD domain.
The error code '17 (Failure setting user credentials)' indicates some authentication issue. Typical examples are a wrong password or different times on the Linux client and the AD DC. The krb5_child.log might contain more details. See the link Jakub send above for details how to enable debugging.
HTH
bye, Sumit
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On (10/06/16 11:45), ahkaplan@partners.org wrote:
Hello --
We are running the 14.04.3 LTS 64-bit release as a virtual machine on a Vmware appliance. The goal of the installation is to create a Samba server that utilizes Active Directory authentication. To that end I utilized the following procedure:
Ubutu 14.04 has very buggy version of sssd 1.11.5 Please test with more stable version. You can use ppa https://launchpad.net/~sssd
LS
sssd-users@lists.fedorahosted.org
-
ahkaplan＠partners.org -
Jakub Hrozek -
Lukas Slebodnik -
Sumit Bose