Can't login with domain account via ssh in Lucid

Bug #567473 reported by David Leon
34
This bug affects 7 people
Affects Status Importance Assigned to Milestone
likewise-open (Ubuntu)
Incomplete
Undecided
Gerald Carter

Bug Description

Binary package hint: likewise-open

Can't login with domain account with likewise-open via ssh

When connecting via ssh to Ubuntu Lucid running likewise-open and correctly joined to a domain:

DOMAIN\myusername@server:~$ ssh localhost
Password:
Connection to localhost closed by remote host.
Connection to localhost closed.

Same thing happens from Debian and Ubuntu Karmic

Password was correct. Logs show session was opened and closed.

The server joined the domain under Ubuntu Karmic, and is now running Ubuntu Lucid (upgraded on 2010-04-12 and updated today 2010-04-20). likewise-open package is 5.4.0.42111-2ubuntu1. Likewise is functioning correctly, accepting local sessions with this account, and correctly rejects wrong passwords via ssh. SSH logins with local users work correctly.

It seems to crash with:
login_get_lastlog: Cannot find account for uid 1015036139
So I set PrintLastLog no in /etc/ssh/sshd_config and now crashes with:
login_init_entry: Cannot find user "DOMAIN\\myusername"

Attached are logs attempting connections from Debian to Lucid with and without PrintastLog. Also a log with a successful connection Debian->Karmic with the same account.

Tags: lucid
Revision history for this message
David Leon (fongsled) wrote :
Revision history for this message
David Leon (fongsled) wrote :
Revision history for this message
David Leon (fongsled) wrote :
David Leon (fongsled)
tags: added: lucid
Revision history for this message
Gerald Carter (coffeedude.jerry) wrote :

David, I've tried and cannot reproduce this. I would suggest trying the latest proposed debs from
https://launchpad.net/~likewise-open/+archive/likewise-open-ppa but there is honestly no change in there that I can think of that would impact ssh logins.

What happens when you run "getent passwd 1015036139" and "id" as the user.

Changed in likewise-open (Ubuntu):
status: New → Incomplete
assignee: nobody → Gerald Carter (coffeedude.jerry)
Revision history for this message
David Leon (fongsled) wrote :

Actually, It seems to be working now.

I don't know if this is related, but today when I logged in, I noticed my home directory changed to /home/likewise-open/DOMAIN/myusername, when it used to be /home/DOMAIN/myusername. Apparently, one of the upgrades (karmic->lucid, partial upgrade) changed this, and the gdm login only picked it up now after caches expired. Maybe ssh was breaking because of this mismatch? This is, of course, a bug, as the home directory location changed and the files weren't moved, I just got an empty home. After fixing it with lw-edit-reg, clearing the cache, rebooting, waiting for the cisco router to bring up the connection and for likewise to notice the DC was up, I managed to login and got the home directory back. SSH works now.

I have etckeeper running, and can provide configuration changes during the upgrade. Should I file a separate bug?

Currently I get:
DOMAIN\myusername@client:/etc$ getent passwd 1015036139
DOMAIN\myusername:x:1015036139:1015022081:LEON David Z:/home/DOMAIN/myusername:/bin/bash
DOMAIN\myusername@client:/etc$ id
uid=1015036139(DOMAIN\myusername) gid=1015022081(DOMAIN\domain^users) groups=121(admin),1015022081(DOMAIN\domain^users)

Revision history for this message
Gerald Carter (coffeedude.jerry) wrote :

> I have etckeeper running, and can provide configuration
> changes during the upgrade. Should I file a separate bug?

Please do. Just about the change in home directory path since it should have been migrated from the previous likewise-open package. Also include whether you upgraded from likewise-open or likewise-open5. Thanks.

Revision history for this message
Marcos Saraiva (msaraiva) wrote :

SSH does not work here either (for domain users).

ti@ltsp-ubuntu1004-test:~$ getent passwd 1652032633
marcos.saraiva:x:1652032633:1652032001:Marcos Saraiva:/u01/home/ESPLANADA/marcos.saraiva:/bin/bash

ti@ltsp-ubuntu1004-test:~$ LANG=en_US ; id 1652032633
id: 1652032633: No such user

AssumeDefaultDomain is set to 1, and i'm using the latest ppa package.

Revision history for this message
Marcos Saraiva (msaraiva) wrote :

I also get this when logging on a local console with the same user:

groups: cannot find name for group ID 1652032001

Revision history for this message
David Leon (fongsled) wrote :

FWIW, my ssh stopped working again, even after fixing the home directory and upgrading to the latest PPA deb. I don't know if it involves some sort of timeout and that's why I could login at first.

Interestingly I can scp and sftp to that machine without problem. It's only the interactive login that fails. In fact I can work around this with "ssh server -X -f gnome-terminal". SSO won't work in that case but after a little while I get a terminal I can use with just an error:
(gnome-terminal:13135): Gtk-CRITICAL **: gtk_accel_map_unlock_path: assertion `entry != NULL && entry->lock_count > 0' failed

Single-sign-on doesn't work in any case using 10.04 as server.

Revision history for this message
Marcos Saraiva (msaraiva) wrote :

Any news on this? Pretty much a show-stopper for 10.04 for server purposes (mainly LTSP, here).

Revision history for this message
James Stuart (james-stuart) wrote :

I can confirm this issue on both server and desktop. After upgrading from 9.04 to 9.10 to 10.04, I was unable to login using domain credentials via SSH. SFTP worked fine.

The issue was resolved, at least for me, by fixing a problem in /etc/security/group.conf. I was using group.conf to add system groups to domain users and, during the upgrade, some of the system groups went away. After removing the groups that were no longer present on the system (in my case vboxusers) SSH logins were possible using domain users.

My authlog looked something like this:

pam_krb5(sshd:auth): user user authenticated as user@DOMAIN
Accepted keyboard-interactive/pam for user from 123.123.123.123 port 41388 ssh2
pam_group(sshd:setcred): bad group: vboxusers
pam_unix(sshd:session): session opened for user user by (uid=0)
pam_group(sshd:setcred): bad group: vboxusers
fatal: login_get_lastlog: Cannot find account for uid 123456789
pam_unix(sshd:session): session closed for user user
syslogin_perform_logout: logout() returned an error

After fixing the group problem:

pam_krb5(sshd:auth): user user authenticated as user@DOMAIN
Accepted keyboard-interactive/pam for user from 123.123.123.123 port 55842 ssh2
pam_unix(sshd:session): session opened for user user by (uid=0)

In theory, this should fail much more gracefully than just preventing domain logins.

I hope this helps...

Revision history for this message
Guimenez (guimenez) wrote :

Please, the same thing its happening here. I'm using Ubuntu 10.10 and i can't login at mine server and my ubuntu is joined to AD.

the gdm login doesn't give any error just ask again for another user.

if i put kinit user
it works well

any help please?

thanks

Revision history for this message
Andreas (andreas-kotowicz) wrote :

same problem here (Ubuntu 10.04.1 LTS):

- sftp works, I can copy files onto the server (here are the logs):

Accepted keyboard-interactive/pam for bla\\user from x.x.x.x port 60984 ssh2
pam_unix(sshd:session): session opened for user bla\user by (uid=0)
Received disconnect from x.x.x.x: 11: disconnected by user
pam_unix(sshd:session): session closed for user bla\user
pam_env(sshd:setcred): No such user!?

- ssh authentication is ok, but I get disconnected instantaneously

Accepted keyboard-interactive/pam for bla\\user from x.x.x.x port 40149 ssh2
pam_unix(sshd:session): session opened for user bla\user by (uid=0)
fatal: login_get_lastlog: Cannot find account for uid 1530400065
pam_unix(sshd:session): session closed for user bla\user
syslogin_perform_logout: logout() returned an error

- su bla\\user works.

I have likewise-open_5.4.0.42111-2ubuntu1.2_i386.deb installed.

anymore hints? suggestions?

Revision history for this message
Scott Salley (ssalley) wrote :

I'm the packager for likewise-open and I suggest going to the Likewise forums at http://www.likewise.com/community/index.php/forums and posting of your problem there. They have been very responsive and are pretty good at figuring these issues out.

Revision history for this message
Andreas (andreas-kotowicz) wrote :

I've uninstalled likewise-open and have installed the latest likewise version from http://www.likewise.com/community/index.php/download/

now everything works for me.

Revision history for this message
Helge Willum Thingvad (helgesdk) wrote :

I also just installed the newest version from likewise.com on my Ubuntu 10.04, and the problem seems to have been resolved.

Running sshd with LogLevel DEBUG showed that I was authenticated through likewise and mapped to a seemingly correct uid, but when trying to utilize the uid after the SSH session had been established, e.g. when displaying lastlog, the uid and username could not be found by the system (wtf?!).
Using "getenv passwd <uid>" showed that the user did exist on the system... weird.

I have attached the output from "lsassd --loglevel debug" with one login attempt - enjoy ;-)

Anyway, this is what I did to install the newest likewise version:

Install the software:
 wget http://www.likewise.com/bits/6.0/8388/LikewiseOpen-6.0.0.8388-linux-amd64-deb.sh
 chmod +x LikewiseOpen-6.0.0.8388-linux-amd64-deb.sh
 sudo ./LikewiseOpen-6.0.0.8388-linux-amd64-deb.sh
Append the likewise bin-directory to PATH in /etc/environment:
 PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/likewise/bin:/opt/likewise/sbin"
To make the PATH work for sudo also, you need to set secure_path in /etc/sudoers:
 Defaults env_reset
 Defaults secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin:/opt/likewise/bin:/opt/likewise/sbin
(the default secure_path is described in /usr/share/doc/sudo/OPTIONS)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.