LTSP thin clients cant login with domain users?

[pixxure]

Hello,

I have installed LTSP and created a 32 bit image.  I can boot a thin client now, but i can only login with the zentyal "main" account i created during the installation of zentyal.

I tried to login with some of the domain users i created ( zentyal acts as a pdc as well)  but then i get the error "no response from server"
also when i log in with the "main" account, in the dashboard it still says that there are 0 users connected to LTSP

am i doing something wrong?

regards,

sander

[Neru]

Hello pixxure,

do you have PAM enabled in your server?

Regards.

[pixxure]

hello,

well i have tried both with PAM enabled and PAM disabled.   When PAM is disabled, i can login with the "main"account on the thin client but not with any domain accounts.

When i enable PAM, however, i can not login with any account anymore. even the "main" account does not login anymore but gets the message "no response from server

[Neru]

Can you please try 'ssh user@localhost' in the Zentyal server with one of those users and post the results here?

[pixxure]

interestingly enough nothing happens. i cant open the administrators console anymore. 

i thought a reboot would fix it, but it hasnt..  it seems like it hangs completely when you try to open the administrators console. but it doenst hang, it takes a long time ( >5 mins) to open the administrators console.  when i type:  ssh user@localhost   it asks from the password for user@localhost and then after a long wait : connection closed by 127.0.0.1

[jsalamero]

Then I guess your problem is with PAM authentication and not with Thin Clients. Since I guess you are using 2.3 might be a bug of the beta version, if you can reproduce this from a clean install, can you report the issue in the trac, please?

[canna3is]

Hi

Same Issue here.
Got this with ssh login on the server.

Code: [Select]

root@zentyal:/home/sa# ssh bela@localhost
The authenticity of host 'localhoat (127.0.0.1)' can"t be established.
ECDSA key fingerprint ce:**************
Are you sure you want to connecting (yes/no)? yes
warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
bela@localhost's password:
Permission denied, please try again.
bela@localhost's password:

Sa is the admin user. Login with sa is allowed on the thin client desktop too.
Thanks

Karoly

[pixxure]

ok i will reinstall everything and then try again. if the problem persists, i will enter it in the trac.

[canna3is]

ok i will reinstall everything and then try again. if the problem persists, i will enter it in the trac.

Hi
Any progress in your thread ?

[robb]

If I remember correctly, when you enable PAM, it is only for accounts created after enabling PAM. At least, that's how it works in 2.2

[canna3is]

If I remember correctly, when you enable PAM, it is only for accounts created after enabling PAM. At least, that's how it works in 2.2

Yes I did it in this way. The point We should focus on can be the other topic dealing with the users and samba module working together thing. Maybe that is why thin client doesn't work well.

[pixxure]

i did a fresh install of zentyal and now it seems to work.  but indeed i also created users after activating PAM

[ira]

Just found this topic, been having issues with this for a while. Bug report is here: http://trac.zentyal.org/ticket/4764

I've found that the login issue can be fixed by overriding the PAM settings with

Code: [Select]

sudo pam-auth-update --force but this probably breaks a few other things.

Looking at the changes this makes it looks like it pam-auth-update gets rid of kerberos authentication and adds LDAP:

Code: [Select]

default /etc/pam.d/common-session as set by pam-auth-update:

session [default=1]                     pam_permit.so
session requisite                       pam_deny.so
session required                        pam_permit.so
session optional                        pam_umask.so
session required      pam_unix.so
session optional                        pam_ldap.so

not working zentyal /etc/pam.d/common-session:

session [default=1]         pam_permit.so
session requisite           pam_deny.so
session required            pam_permit.so
session optional            pam_umask.so
session optional            pam_krb5.so minimum_uid=1000
session required            pam_unix.so
session required            pam_mkhomedir.so skel=/etc/skel/ umask=0077

default /etc/pam.d/common-password as set by pam-auth-update:

password        [success=2 default=ignore]      pam_unix.so obscure sha512
password        [success=1 user_unknown=ignore default=die]     pam_ldap.so use_authtok try_first_pass
password        requisite                       pam_deny.so
password        required                        pam_permit.so

not working zentyal /etc/pam.d/common-password:
password    [success=2 default=ignore]  pam_krb5.so minimum_uid=1000
password    [success=1 default=ignore]  pam_unix.so obscure use_authtok try_first_pass sha512
password    requisite           pam_deny.so
password    required            pam_permit.so


default /etc/pam.d/common-account as set by pam-auth-update:

account [success=2 new_authtok_reqd=done default=ignore]        pam_unix.so
account [success=1 default=ignore]      pam_ldap.so
account requisite                       pam_deny.so
account required                        pam_permit.so


not working zentyal /etc/pam.d/common-account:

account [success=1 new_authtok_reqd=done default=ignore]    pam_unix.so
account requisite           pam_deny.so
account required            pam_permit.so
account required            pam_krb5.so minimum_uid=1000



default /etc/pam.d/common-auth as set by pam-auth-update:

auth    [success=2 default=ignore]      pam_unix.so nullok_secure
auth    [success=1 default=ignore]      pam_ldap.so use_first_pass
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

not working zentyal /etc/pam.d/common-auth:

auth    [success=2 default=ignore]  pam_krb5.so minimum_uid=1000
auth    [success=1 default=ignore]  pam_unix.so nullok_secure try_first_pass
auth    requisite           pam_deny.so
auth    required            pam_permit.so
And no, it doesn't work with new users created after enabling PAM.

[christian]

Looking at the changes this makes it looks like it pam-auth-update gets rid of kerberos authentication and adds LDAP:

Very interesting point 

With Kerberos introduction in the landscape, the expectation is, in an ideal world, not to have either LDAP or Kerberos but to use Kerberos as main (not to say unique) authentication back-end while LDAP should be used as main profiling back-end with, in case LDAP authentication is required, use of Kerberos as authentication mechanism thanks to GSSAPI.
However, I'm not sure all LDAP clients are able to switch that easily from LDAP "simple bind" to GSSAPI.
I definitely need to learn a bit more about this 

[ira]

Bug found!

Missed a line in two of the files, as they weren't at the end of the text like most files modified by zentyal. The problem is in following line in common-auth:

auth   [success=1 default=ignore]   pam_ldap.so use_first_pass
auth    [success=2 default=ignore]  pam_krb5.so minimum_uid=2000
auth    [success=1 default=ignore]  pam_unix.so nullok_secure try_first_pass
auth    requisite           pam_deny.so
auth    required            pam_permit.so

The 'success=1' in common jumps the next line in the stack. But it doesn't even get that far, as the use_first_pass option tries to use a password that was never entered as this line is the first in the stack and fails without a prompt. The success=1 takes it to pam_unix where it fails authentication. success=3 is correct option and removal of use_first_pass makes it prompt for a password.


Then there's this line in common-account:

account [success=1 default=ignore]      pam_ldap.so
account [success=1 new_authtok_reqd=done default=ignore]    pam_unix.so
account requisite           pam_deny.so
account required            pam_permit.so
account required            pam_krb5.so minimum_uid=2000

This jumps the success straight to a pam_deny module and so account verification fails. Change it to success=2 and it jumps to pam_permit like it should. Looks like that Kerberos line should be up there above pam_deny too.

After these changes thinclients can login fine.

My first bug found! Didn't know anything about PAM yesterday before I tried to fix this so I'm pretty happy