Authentication for edit-from-my-PC
I am wondering about the connection between SSO, LDAP, passwords and GoFAST or edit-from-my-PC.
We have an LDAP from which user information is fetched, and an SSO (potentially with 2fa). We authenticate against the SSO.
Now we may have a specific situation in that the LDAP is not the main source for the SSO user directory. (Synchronisation setup is a different topic which is on our side, let us just say we use the LDAP as a list of valid users and source of userlists, and all authentication is done against SSO). The main point is that passwords may differ between LDAP and SSO, if the SSO account has a changed password and the LDAP not.
SSO and user information are fine and work together. We log in to GoFAST and do all kinds of things. But for edit-from-my-PC, I need to provide a different username/password, and I found I sometimes need to use an old password, and sometimes I cannot make it work at all.
- Am I right that the edit-from-my-PC ignores the SSO?
- If yes, does it try to connect to LDAP on the fly at the moment of the start of the service? Or is there some other mechanism?
- What may make the service block (bearing in mind that this has worked for a long time and now stopped working?)
Am I right that the edit-from-my-PC ignores the SSO?
To our knowledge yes SSO is ignored by MS-Office, unless perhaps your SSO is creating also a Kerberos ticket (Windows own SSO) see: https://www.keycloak.org/docs/6.0/server_admin/#_kerberos
If yes, does it try to connect to LDAP on the fly at the moment of the start of the service? Or is there some other mechanism?
The usual behavior is that MS-Office requests a webdav authorization to Alfresco with the GoFAST login and password. This password can be the GoFAST password or the LDAP/AD password if authentication/delegation is in place (SASL). Keep in mind that in MS-Office 2016 and newer version, Office "remember" the login/password and the authentication popup is not displayed at each document open.
What may make the service block (bearing in mind that this has worked for a long time and now stopped working?)
Can you explain what you mean by "service blocks" ?
Thank you!. Indeed, that is helpful already; so the webdav authentication would be against whatever is the valid auth provider in GoFAST, which would be the LDAP.
"What makes the service block"...~What I mean: On my laptop with Office 2016 I got the webdav auth request displayed, and after some trial and error I managed to login using the former password (not valid anymore in any instance but in the special LDAP instance used by GoFAST). OK.
On the VM at the Office that still has Office 2010, no password, neither old nor new, works on teh same webdav auth form; that is what I meant with blocking.
I had used the same many many times during the last few weeks without being asked for the username/password, and without problem (One of the reasons why I was so puzzled when it stoopped working). I now think that somehow until last week, the webdav auth might have been still valid without special check, and the system did not ask. With the latest restart and updates last week, that may have been the point when it stopped, as somehow something does not fit anymore.
I have no idea why it now works with teh old password on the laptop but not on the VM. Ideas are welcome, but not very important; I need to have the configurations between LDAP and keycloak synched.
We made a security fix recently (3.8.0 Hotfix 6) that may be the cause of your issue.
Could you try to open a document with another computer running Office 2010 if you are able ?
Also could you send me the error(s) message(s) you get ?
Thanks in advance for you help !
I tested now with a different user (who kept the same password as weeks ago), on the same machine with Office 2010 and on a second machine with Office 2010. It is indeed the same problem, so it is not anything about a changed password.
Error message: Well, there is no obvious error message. Word is being opened, with the alfresco ticket being downloaded 0%, and the windows security dialogue opens again and again and asks for the password
There is no explicit error message that I can find. In the event viewer, the information is just
Could not open 'https://servername/TICKET_925c048779dcc2c50f70df835ac8853e09a9b70d/alfresco/webdav/Sites/_Path-to-doc/doc.docx'.
Hello @aclassen ,
Thank you for your help ! Yes it seems to be related to the desactivation of these unsecured cyphers :
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 128
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 128
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 256
Do you know when the Office 2010 workstations will be updated ? I think it should be soon because the EOL of Office 2010 is the next month.
Thanks in advance !
Could you give me the permission to temporary enable these cyphers again to check if this is the cause of the issue ?
Even if we don't recommand that we may be able to re enable these cyphers keeping your support licencing active with a signed agreement, waiting for the Office 2010 update.