VMware Horizon Community
BenMax
Contributor
Contributor
Jump to solution

Horizon 7.5, Ubuntu 16.04 and still SSO issues

Hello,

from 7.1 to 7.5, I never succeded make SSO function properly.

Whatever I do or i read Il still appears a vmware-sso login screen and I can go forward with a simple 'enter'.

So why my SSO process can't go directly in session bypassing that awful login screen ?

This is what i can read in view agent debug log file

2018-07-24T09:32:07.482Z INFO  <MKSControlIPCThread> [SsoHandler] Run SSO ConfigDesktopType finish

2018-07-24T09:32:07.482Z DEBUG <MKSControlIPCThread> [SsoHandler] Send the SSO notify

2018-07-24T09:32:07.483Z DEBUG <MKSControlIPCThread> [SsoHandler] params= [/usr/lib/vmware/viewagent/bin/SsoDBusNotify.py, -t, sso]

2018-07-24T09:32:07.501Z DEBUG <Script Runner> [LinuxUtilities] Running script: /usr/lib/vmware/viewagent/bin/SsoDBusNotify.py

2018-07-24T09:32:07.528Z DEBUG <Script Runner> [LinuxUtilities] waiting for process to terminate, script: /usr/lib/vmware/viewagent/bin/SsoDBusNotify.py

2018-07-24T09:32:08.895Z DEBUG <Script Stdout> [LinuxUtilities] INFO:root:Emitting user authenticated SSO signal.

2018-07-24T09:32:08.950Z DEBUG <SSOThread> [SsoHandler] Accept sso connection

2018-07-24T09:32:08.951Z DEBUG <SSOThread> [SsoHandler] Expect sso token: <Token>

2018-07-24T09:32:08.951Z DEBUG <SSOThread> [SsoHandler] Recevie sso token: <Response token>

2018-07-24T09:32:08.951Z DEBUG <SSOThread> [SsoHandler] Send sso creds for <userid>

2018-07-24T09:32:08.993Z DEBUG <Script Stdout> [LinuxUtilities] Please input the token:

2018-07-24T09:32:08.994Z DEBUG <Script Runner> [LinuxUtilities] process terminated with rc 0, script: /usr/lib/vmware/viewagent/bin/SsoDBusNotify.py

2018-07-24T09:32:08.994Z DEBUG <Script Runner> [LinuxUtilities] Script finished: /usr/lib/vmware/viewagent/bin/SsoDBusNotify.py

2018-07-24T09:32:09.018Z DEBUG <Script Stdout> [LinuxUtilities] finished

2018-07-24T09:32:09.018Z DEBUG <Script Runner> [LinuxUtilities] thread finished...

2018-07-24T09:32:09.028Z INFO  <MKSControlIPCThread> [SsoHandler] Run ssoDBusNotify script finish

2018-07-24T09:32:09.028Z DEBUG <MKSControlIPCThread> [StandaloneAgent] Start session ttl timer with timeout:35997829

I am working with ubuntu 16.04, gnome session flashback, winbind (with param 'winbind use default domain = true')

For now, there is just one machine (the template) in desktop pool.

Any help woul be very appreciate.

Max B

0 Kudos
1 Solution

Accepted Solutions
BenMax
Contributor
Contributor
Jump to solution

Almost 4 years later... finally got it.

Context :

ubuntu (many versions and flavors tested) and winbind authentication

Solution :

in /etc/pam.d/common-auth, comment the  line calling the pam_krb5.so module

auth [success=2 default=ignore] pam_unix.so nullok try_first_pass
auth requisite pam_vmw_null.so
#auth [success=4 default=ignore] pam_krb5.so minimum_uid=1000
auth [success=1 default=ignore] pam_winbind.so krb5_auth try_first_pass

Explanation (IMHO) :

Installing libpam_krb5 which is needed for both kerberos and winbind authentication, introduces the line to comment in common_auth.
In classical installation, this is not a problem. Calling direct Kerberos module will produce an error and authentication continues with pam_winbind module.

In horizon SSO context, the gdm-vmwcred module acts correctly but pam_winbind provokes an  incorrect password error message.
Since between the vmware module and the winbind module there is this kerberos module and both uses kerberos, I assume that the password is not provided to the winbind and maybe intercepted by the kerberos module that cannot use it since it is not in the active directory context.

Commenting the line makes the winbind module directly receives the password from the vmware module.

 

View solution in original post

0 Kudos
1 Reply
BenMax
Contributor
Contributor
Jump to solution

Almost 4 years later... finally got it.

Context :

ubuntu (many versions and flavors tested) and winbind authentication

Solution :

in /etc/pam.d/common-auth, comment the  line calling the pam_krb5.so module

auth [success=2 default=ignore] pam_unix.so nullok try_first_pass
auth requisite pam_vmw_null.so
#auth [success=4 default=ignore] pam_krb5.so minimum_uid=1000
auth [success=1 default=ignore] pam_winbind.so krb5_auth try_first_pass

Explanation (IMHO) :

Installing libpam_krb5 which is needed for both kerberos and winbind authentication, introduces the line to comment in common_auth.
In classical installation, this is not a problem. Calling direct Kerberos module will produce an error and authentication continues with pam_winbind module.

In horizon SSO context, the gdm-vmwcred module acts correctly but pam_winbind provokes an  incorrect password error message.
Since between the vmware module and the winbind module there is this kerberos module and both uses kerberos, I assume that the password is not provided to the winbind and maybe intercepted by the kerberos module that cannot use it since it is not in the active directory context.

Commenting the line makes the winbind module directly receives the password from the vmware module.

 

0 Kudos