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
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.
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.