Cannot proceed to https://manager.sso....

[fawqsir]

I have setup lemonldap as per you example file. when I log in to https://manager.sso.... The console shows I have logged in.

[Fri Sep 27 08:01:26 2019] [LLNG:1106] [notice] Session granted for dwho by Demo (192.168.1.243)
[Fri Sep 27 08:01:26 2019] [LLNG:1106] [notice] User dwho successfully authenticated at level 1
[Fri Sep 27 08:01:26 2019] [LLNG:1106] [notice] dwho connected
Status: Unknown command line : RELOADCACHE Cache::FileCache5

however I cannot proceed any farther. The webpage is still asking

Authentication required

and the address is https://sso.... with a token attached and not https://manager.sso....

[tiredofit]

Hm - not entirely what's happening there without being able to look at it fully - That's definitely not normal behaviour. I will start a new install and see if I can replicate.

In the meantime, change your env var to SETUP_TYPE=MANUAL
And in your ./data/etc/lemonldap-ng/lemonldap-ng.ini and change the section where it says:

[manager]
protection=manager

to

[manager]
protection=none

and then restart the container. This will at least allow you to kick the tires while I try to recreate.

[fawqsir]

I am testing out a theory that it could be due to letsencrypt certs. I am using jwilders nginx proxy with the letsencrypt companion. The sso.... cert is used for all manager.sso... and handler.sso.... with just a link.. Could this be part of the problem?

There is a beta feature. That may correct the problem.

[tiredofit]

Hmm - unless something has changed with browsers I'm not sure that may be it. I ran that exact docker-compose for 2 years and nginx proxy with no issues sharing the same certificate. I've since moved onto Traefik - but it works very similar.

You can try this (replace example.com) on your domains to see how they respond perhaps?

echo | openssl s_client -showcerts -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -inform pem -noout -text

[Bobonium]

It's been quite some time since anything has been posted here, but I just faced the same problem that was described here, and I was able to find the exact problem

The problem here is that the auto generated config is incorrect if you choose any domain that is not example.com.
You can check this for yourself by starting a container with environment variables pointing to any other domain and then grepping for example.com in the /var/lib/lemonldap-ng/conf/lmConf-1.json

The reason that this breaks the login is because if you check the response headers after a successful login it will set the session cookie for the domain that is configured as domain within said config file. As this is hardcoded to example.com the session cookie will not be used by any browser afterwards as it's meant for a different domain.

Since the other occurences of example.com within the same file are actually replaced based on the environment variables it might make sense to introduce the SSODOMAIN variable that is available in the test image https://github.com/LemonLDAPNG/lemonldap-ng-docker/blob/6d7cbfe67115af77619a3f8bd79bb5e0de00ede4/docker-trunk/centos/7/apache2/docker-entrypoint.sh#L8

[tiredofit]

Thanks for this, I thought I had changed enough in the default configuration file to account for this, but obviously not.
Lines 93-98 of install/etc/cont-init.d/10-lemonldap show the configuration upon first startup where I do change any references of example.com to the variable of $DOMAIN_NAME. Do you have that set as well?

[Bobonium]

No I actually did not set DOMAIN_NAME, but I can confirm that it works as intended after setting that as well. I checked the README once more and this variable is completely missing from there, which is why I never set it initially.

[tiredofit]

You're right - When I first responded I second guessed myself that I hadn't updated it and looked at the README on my system, while it existed on my local copy/private org copy I haven't updated the README on github with the information. I'll move it over from my orgs git repository and apologize for the confusion. It's been there for a long time but I missed moving it over. Can you try to see if the addition gets you going and we can close this off once I push new README info?

[Bobonium]

Don't worry about it, I also could've had a look at the code first but simply didn't.
Yes, I tested it already and setting the DOMAIN_NAME does indeed resolve the issue, so I think you can close this if you document it in the README

[Bobonium]

Haha, I just realized it is actually already part of the README, but it seems there was an error and you removed the new line in one of your commits, which is why it is not rendered anymore as it would break the table layout.

52f6941#diff-04c6e90faac2675aa89e2176d2eec7d8R116

[tiredofit]

Ahh jeez, confusion caused by 1 byte. I've updated README now :)