No chance to get Single-Sign On working

saml
ucs4
sso

#1

hi,
i tried to setup my ucs master with sso.
i installed a win10 test client and joined the domain.
I configured everything as written in these threads regarding “imprt ucs root ca on windows client” 1 and “configuring windows for SSO with kerberos” 2.
I checked the settings on the client, the group policies are executed as expected.

I am able to visit the website https://ucs-sso.domain.ltd which shows a blank page with the univention writing in the top right corner (screenshot).
certificates are from letsencrypted.
I checked the join scripts 91 and 92, both finished with EXITCODE=0
I am able to reach the ucs-sso.domain.ltd from the client with ping, so the dns should work fine.

My problem:
I´m logged in as a ucs-user with permission for kopano, nextcloud, ucs
If call the univention startpage with IE or Google Chrome, than i have to log in again (in UCS or Nextcloud or kopano) …
I noticed, that on the login page is only the writing “How can i log in” and no special SSO-writing i´ve found in a thread, i don´t know if this is important.

So, can somebody give me a hint to challenge SSO?
thanks in advance,
hanspeter

my system: UCS4.3

image


#2

Hi @hpz,

I don’t know the answer but have some suggestions on what to check. You write that you see a mostly blank page, when going so ucs-sso.domain.tld. How does the site look, when visiting from a machine that is not joined to the domain?

At least for the Univention portal page the sso login should work (so when going to ucs.domain.tld//univention/management/ you do not have to login, if your kerberos session logged you in already). I cannot say though if in Nextcloud Saml is already preconfigured. I can only say with certainty that Kopano WebApp does not care about Saml.


#3

hi fbartels,
thanks for your reply.

  1. ) I tried to visit the ucs-sso.domain.ltd from an “unjoined” computer and it looks like the same as on domain client (see my screenshot in the first posting)

2.) if i surf the ucs.domain.tld//univention/management/ on the joined client, i get an login page (where i shouldn´t not

3.) Okay, i thought that the apps are automatically configured for SAML…

summa sumarum: SSO isn´t working


#4

Please have a look at our debugging kerberos login article and check if everything is working correctly. Additional information may be logged in the logfiles mentioned in the article when trying to access the UMC.


#5

another hint. I just checked on my system and when I directly go to the sso subdomain the page I see is also not showing a login bar. But I think this is acutally rather normal. When I login to “/univention/management/” it redirects to ucs-sso.domain.tld and then shows the login mask (I am not joined to a domain and therefore see the mask), for joined system i would expect some “redirect flicker” and then being redirected to the desired application.


#6

hi,
thanks for your ideas, which i´ve tried today:

@damrose: i worked through the whole list and everythings seems to work fine:

  • UCR variable is changed
  • SAML identity provider shows up in Intranet Sites in the IE settings
root@dc:/var/log/apache2# univention-check-templates 2>&1 | egrep "(apache|saml)"
root@dc:/var/log/apache2# 
root@dc:/var/log/apache2# ktutil --keytab=/etc/simplesamlphp.keytab list
/etc/simplesamlphp.keytab:

Vno  Type                     Principal                             Aliases
  2  des-cbc-crc              HTTP/ucs-sso.domain.ltd@domain.ltd  
  2  des-cbc-crc              ucs-sso@domain.ltd                   
  2  des-cbc-md5              HTTP/ucs-sso.domain.ltd@domain.ltd  
  2  des-cbc-md5              ucs-sso@domain.ltd                   
  2  arcfour-hmac-md5         HTTP/ucs-sso.domain.ltd@domain.ltd  
  2  arcfour-hmac-md5         ucs-sso@domain.ltd                   
  2  aes128-cts-hmac-sha1-96  HTTP/ucs-sso.domain.ltd@domain.ltd  
  2  aes128-cts-hmac-sha1-96  ucs-sso@domain.ltd                   
  2  aes256-cts-hmac-sha1-96  HTTP/ucs-sso.domain.ltd@domain.ltd  
  2  aes256-cts-hmac-sha1-96  ucs-sso@domain.ltd                   
  1  des3-cbc-sha1            HTTP/ucs-sso.domain.ltd@domain.ltd  
  1  des-cbc-md4              HTTP/ucs-sso.domain.ltd@domain.ltd  
  1  arcfour-hmac-md5         HTTP/ucs-sso.domain.ltd@domain.ltd  
  1  aes128-cts-hmac-sha1-96  HTTP/ucs-sso.domain.ltd@domain.ltd  
  1  aes256-cts-hmac-sha1-96  HTTP/ucs-sso.domain.ltd@domain.ltd  
  1  des-cbc-md5              HTTP/ucs-sso.domain.ltd@domain.ltd  
  1  des-cbc-crc              HTTP/ucs-sso.domain.ltd@domain.ltd  
  1  des3-cbc-sha1            HTTP/ucs-sso.domain.ltd@domain.ltd  
  1  des-cbc-md4              HTTP/ucs-sso.domain.ltd@domain.ltd  
  1  arcfour-hmac-md5         HTTP/ucs-sso.domain.ltd@domain.ltd  
  1  aes128-cts-hmac-sha1-96  HTTP/ucs-sso.domain.ltd@domain.ltd  
  1  aes256-cts-hmac-sha1-96  HTTP/ucs-sso.domain.ltd@domain.ltd  
  1  des-cbc-md5              HTTP/ucs-sso.domain.ltd@domain.ltd  
  1  des-cbc-crc              HTTP/ucs-sso.domain.ltd@domain.ltd  
root@dc:/var/log/apache2# 

Then i make a test and call the website ucs-sso.domain.ltd on my domain-joined client.
I logged in with my user, the url is changing to https://domain.ltd/simplesamlphp/module.php/core/frontpage_welcome.php and i get an 404 error page!

Content of my access.log and error.log:

access,log:

192.168.24.80 - - [15/Oct/2018:10:23:12 +0200] "POST /univention/auth HTTP/1.1" 200 854 "https://domain.ltd/univention/login/?location=%2Fsimplesamlphp%2Fmodule.php%2Fcore%2Ffrontpage_welcome.php&lang=de-AT" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko"
192.168.24.80 - - [15/Oct/2018:10:23:12 +0200] "GET /univention/get/meta?1539591792481 HTTP/1.1" 200 1821 "https://domain.ltd/univention/login/?location=%2Fsimplesamlphp%2Fmodule.php%2Fcore%2Ffrontpage_welcome.php&lang=de-AT" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko"
192.168.24.80 - - [15/Oct/2018:10:23:12 +0200] "GET /simplesamlphp/module.php/core/frontpage_welcome.php HTTP/1.1" 404 642 "https://domain.ltd/univention/login/?location=%2Fsimplesamlphp%2Fmodule.php%2Fcore%2Ffrontpage_welcome.php&lang=de-AT" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko"

error.log:

[Mon Oct 15 10:21:58.779236 2018] [autoindex:error] [pid 7063] [client 192.168.24.80:64103] AH01276: Cannot serve directory /var/www/univention/js/umc/: No matching DirectoryIndex (index.html,index.cgi,index.pl,index.php,index.xhtml,index.htm) found, and server-generated directory index forbidden by Options directive, referer: https://domain.ltd/univention/login/?location=%2Funivention%2Fself-service%2F%23passwordreset&lang=de-AT
[Mon Oct 15 10:22:59.134915 2018] [autoindex:error] [pid 7066] [client 192.168.24.80:64138] AH01276: Cannot serve directory /var/www/univention/js/umc/: No matching DirectoryIndex (index.html,index.cgi,index.pl,index.php,index.xhtml,index.htm) found, and server-generated directory index forbidden by Options directive, referer: https://domain.ltd/univention/login/?location=%2Fsimplesamlphp%2Fmodule.php%2Fcore%2Ffrontpage_welcome.php&lang=de-AT

#7

I have seen this already several times but I can not recall how to fix at the moment. There are some references to bugs which have already been fixed.

Are you using latest release including latest errata updates?

/CV


#8

hi,
surely: 4.3-2 errata270


#9

Does SSO work at all? Your testcase should be logging into Univention Management Console, click the link on the UCS Portal. When logging into the Univention Management Console, what is the URL on the Login page? If it contains simplesamlphp, Single Sign-On is generally working. If the Loginpage is /univention/login, SSO is not working at all.

You should also check if the logged in user on Windows has a valid kerberos ticket for the domain with klist
(I adjusted the debugging article i linked above and added these questions)

[edit] The apache error message Cannot serve directory /var/www/univention/js/umc/:… has nothing to do with your issues.


#10

Testcase: I click on the login-link on the UCS Portal, the URL is:

https://domain.ltd/univention/login/?location=%2Funivention%2Fportal%2F&lang=de-AT

klist on the ucs-master shows:

klist: No ticket file: /tmp/krb5cc_0
root@dc:~# 

Weird, my client is in the ucs-domain, im logged in with an ucs-user, group policy settings are executed - how is that going on?


#11

We can see that your SSO is not working at all. Please revert the SAML configuration by setting ucr set saml/idp/authsource=univention-ldap . Does the login via SSO work now?

If not, check this article: Single Sign On link on UMC login page is crossed out The title and problem description about a crossed out link refer to a previous UCS version, but the solutions still apply and everything from there has to work.

You have to execute klist in the user context you want to use Single Sign-On in. In your case, login as the domain user on Windows, open a shell by starting cmd from the start menu, and execute klist.


#12

Ok, i reverted the settings back to univention-ldap. I restarted my windows client and surf to the UCS Portal. I have to login and the login URL is the same “wrong” again (/univention/login …)

I checked every point from your link:

  • Is the client using a UCS domain nameserver as its nameserver?
    Yes, the first DNS-Server is the IP of my UCS-Master

  • Is the browser able to resolve the http URI http://ucs-sso.<domainname>/?
    Yes, i come to this site “http://ucs-sso.domain.ltd/simplesamlphp/module.php/core/frontpage_welcome.php” and i get the univention logo.

  • Is the correct SSL certificate available in the browser? Can https://ucs-sso.<domainname>/.
    be visited in the browser?

    yes:
    image
    image

  • Is the apache2 site correctly configured? Does·https://ucs-sso.<domainname>/simplesamlphp/blank.json show a small json status document in the browser?
    I get an 404error, but i checked the directory on the ucs-master: There is no blank.json

root@dc:/usr/share/simplesamlphp# ls -la
insgesamt 48
drwxr-xr-x  10 root root  4096 Jun  6 15:31 .
drwxr-xr-x 211 root root 12288 Okt 15 10:12 ..
drwxr-xr-x   2 root root  4096 Jun  6 15:31 bin
lrwxrwxrwx   1 root root    18 Mär  5  2018 config -> /etc/simplesamlphp
drwxr-xr-x   2 root root  4096 Jun  6 15:31 dictionaries
drwxr-xr-x   3 root root  4096 Jun  6 15:31 lib
drwxr-xr-x  54 root root  4096 Jun  6 15:31 modules
drwxr-xr-x   2 root root  4096 Jun  6 15:31 schemas
drwxr-xr-x   3 root root  4096 Jun  6 15:31 templates
drwxr-xr-x   8 root root  4096 Jun  6 15:31 vendor
drwxr-xr-x   6 root root  4096 Jun  6 15:31 www
root@dc:/usr/share/simplesamlphp# 

klist: Sorry, i thought this command sounds like an linux command so i tried it on my ucs-master.
Executed on my windows-client, i get a list back:
image

Once again, thanks for your help!


#13

Hi @hpz

Did you resolve your sso issue? I’ve got similar symptoms!


#14

Hi,
nope, i tried another win-client but get the same result - no sso.


#15

I’m having the exact same problem…

I have done that, and all the others settings as the post explain, but when i went to https://server1.domain.local i get redirected to https://server1.domain.local/univention/portal/ if i try and click in the lock to do the login i then get redirect to https://server1.domain.local/univention/login/?location=%2Funivention%2Fportal%2F&lang=en-US and ask me the username and the password.

note: using internet explorer 11, windows 10

What should be the “main” address that we should put in the browser? https://servername.domain.tld or https://domain.tld ?

My scenario have multiple servers… so:

  • server1
  • server 2 (slave)
  • server 3 (slave)
  • server 4 (slave)

What i see right know is if my logonserver (on windows client is server2) then if i put https://server2.domain.tld and in their click in the lock to do the login the sso works!!!
After the klist command i’m able to see that the server: krbtgt was in server2 all the others are in server1

So what should i change to logon in all the “servers” i don’t have to “find” the right one?


#16

Hi,

I am trying to setup SSO with domain-joined Linux clients (LinuxMint). But I don’t get it working.
I worked through all the articles linked here but no success.
klist returns valid ticket on the client. So that was issued on logging in into the client. Firefox is configured with the ucs-sso as trusted URI. But it does not work.

I also have the issue that calling blank.json returns a 404 error.

Even increasing the log level of SAML IDP did not reveal anything usefull to me.


#17

@jolentes i’m only use windows clients… do you have more than one ucs server?

Thanks


#18

@hpz Your problems could be (not 100% sure) a known issue when using Letsencrypt certificates, see Bug 47700. We are working on fixing this issue.
To the other people who reported a similar issue, are letsencrypt certificates used in your domain? If not, it is probably a different issue which warrants a new thread.


#19

@damrose i’m using a mix setup… for now i’m only want it internal, so the certs in use are the self sign from univention.
That said what @hpz reports is the same thing that i’m getting, blank pages in ucs-sso and form to fill when authtentication is need.

In the meantime like i said… maybe the issue could be the settings because i have multiple servers, and my clients (don’t know why) use slaves servers to logon even when main server is avaiable…

That said, the same windows client machine was able to sso to windows server machine with univention certificate (so sso is working)
The same client machine was able to sso into univention portal when the “portal” was equal do the “logonserver”… so if it would possible access https://%logonserver%.domain.tld/ sso works because that don’t work i must identify the %logonserver% and then put it in the address and sso works.
Problem: the apps shortcuts setup is only in the main server :confused:


#20

@damrose, maybe you can help here… should we access the univention portal as https://domain.tld or https://server.domain.tld if i put the first i randon access one of the servers that i have but, as expected the ssl is invalid because the server name is missing in url…

Is that normal because we should access via https://domain.tld ?