Kaplan, Andrew H.
2016-Jun-08 19:46 UTC
[Samba] Problem with Active Directory authentication
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> Does anyone have thoughts on this? Thanks. The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
Data Control Systems - Mike Elkevizth
2016-Jun-08 22:12 UTC
[Samba] Problem with Active Directory authentication
What does "getent passwd <username>@<domainname>" return on the server for the login shell. By default a samba AD DC sets the login shell for all Active Directory user accounts to /bin/false. The only way I've found to change this, is to override that globally with the "template shell /bin/bash" option in smb.conf, which enables it globally for all Active Directory users (probably not desired). Mike E. On Wed, Jun 8, 2016 at 3:46 PM, Kaplan, Andrew H. <AHKAPLAN at 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: > > 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> > > Does anyone have thoughts on this? > > Thanks. > > > The information in this e-mail is intended only for the person to whom it > is > addressed. If you believe this e-mail was sent to you in error and the > e-mail > contains patient information, please contact the Partners Compliance > HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to you in > error > but does not contain patient information, please contact the sender and > properly > dispose of the e-mail. > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >
> (...) By default a samba AD DC sets the login shell for all > Active Directory user accounts to /bin/false. The only way I've found to > change this, is to override that globally with the "template shell > /bin/bash" option in smb.conf, which enables it globally for all Active > Directory users (probably not desired).Using RFC2307 you can give each user its own shell and home directory. Read here: https://wiki.samba.org/index.php/Setting_up_RFC2307_in_AD
Kaplan, Andrew H.
2016-Jun-09 15:00 UTC
[Samba] Problem with Active Directory authentication
Hello -- The output of the getent passwd command was the following: <username>@<domainname>:*:##########:##########::/PHShome/<username>:/bin/PHSshell ________________________________ From: Data Control Systems - Mike Elkevizth [mike at datacontrolsystems.com] Sent: Wednesday, June 08, 2016 6:12 PM To: Kaplan, Andrew H. Cc: samba-technical at lists.samba.org; samba at lists.samba.org Subject: Re: [Samba] Problem with Active Directory authentication What does "getent passwd <username>@<domainname>" return on the server for the login shell. By default a samba AD DC sets the login shell for all Active Directory user accounts to /bin/false. The only way I've found to change this, is to override that globally with the "template shell = /bin/bash" option in smb.conf, which enables it globally for all Active Directory users (probably not desired). Mike E. On Wed, Jun 8, 2016 at 3:46 PM, Kaplan, Andrew H. <AHKAPLAN at partners.org<mailto:AHKAPLAN at 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: 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> Does anyone have thoughts on this? Thanks. The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
On Wed, Jun 08, 2016 at 07:46:00PM +0000, Kaplan, Andrew H. 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: > > 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.htmlThe sssd-users list https://lists.fedorahosted.org/archives/list/sssd-users at lists.fedorahosted.org/ might be more appropriate for your question. As a general comment, the PAM configuration is important here. Please check the system logs which PAM module was consulted during the login attempt and which cause the rejection. HTH bye, Sumit> > 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> > > Does anyone have thoughts on this? > > Thanks. > > > The information in this e-mail is intended only for the person to whom it is > addressed. If you believe this e-mail was sent to you in error and the e-mail > contains patient information, please contact the Partners Compliance HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to you in error > but does not contain patient information, please contact the sender and properly > dispose of the e-mail.
Kaplan, Andrew H.
2016-Jun-10 11:47 UTC
[Samba] Problem with Active Directory authentication
Hello -- I started a thread on the list that you suggested in your e-mail, and thank-you for the reference. Also, I checked the auth.log file on the server, and the following entries were present: I checked the auth.log file, and the following entries were present: Jun 10 07:10:50 <samba server> 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 <samba server> sshd[7419]: pam_winbind(sshd:auth): getting password (0x00000388) Jun 10 07:10:51 <samba server> sshd[7419]: pam_winbind(sshd:auth): pam_get_item returned a password Jun 10 07:10:51 <samba server> 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 <samba server> sshd[7419]: pam_sss(sshd:auth): received for user username>@<domainname> 17 (Failure setting user credentials) Jun 10 07:10:51 <samba server> sshd[7419]: pam_ldap: could not open secret file /etc/ldap.secret (No such file or directory) Jun 10 07:10:51 <samba server> sshd[7419]: pam_ldap: ldap_simple_bind Can't contact LDAP server Jun 10 07:10:51 <samba server> sshd[7419]: pam_ldap: reconnecting to LDAP server... Jun 10 07:10:51 <samba server> sshd[7419]: pam_ldap: ldap_simple_bind Can't contact LDAP server Jun 10 07:10:53 <samba server> sshd[7419]: Failed password for invalid user username>@<domainname>from <ip address> port 49847 ssh2 ________________________________________ From: Sumit Bose [sbose at redhat.com] Sent: Friday, June 10, 2016 4:44 AM To: Kaplan, Andrew H. Cc: samba-technical at lists.samba.org; samba at lists.samba.org Subject: Re: Problem with Active Directory authentication On Wed, Jun 08, 2016 at 07:46:00PM +0000, Kaplan, Andrew H. 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: > > 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.htmlThe sssd-users list https://lists.fedorahosted.org/archives/list/sssd-users at lists.fedorahosted.org/ might be more appropriate for your question. As a general comment, the PAM configuration is important here. Please check the system logs which PAM module was consulted during the login attempt and which cause the rejection. HTH bye, Sumit> > 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> > > Does anyone have thoughts on this? > > Thanks. > > > The information in this e-mail is intended only for the person to whom it is > addressed. If you believe this e-mail was sent to you in error and the e-mail > contains patient information, please contact the Partners Compliance HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to you in error > but does not contain patient information, please contact the sender and properly > dispose of the e-mail.