Tutorial Authelia - SSO & 2FA portal

[Rusty]

Rusty submitted a new resource:

Authelia - SSO & 2FA portal - open-source authentication server

Intro​

In the world of self-hosting and open-source, there are a lot of great solutions, and some of them might not have a strong user authentification protection, or don't have anything at all, let alone the 2FA option.

For those apps and the fact that you could access all those...

Read more about this resource...

 

[Hydraulics]

Thanks for this Rusty! I took the brave first step to take this on (after finally overcoming Nginx Proxy Mgr).... a few quick questions:

1) I noticed in your guide your second picture shows you setting up your FQDN - blackvoid.home and PW and it shows the "base DN" and Bind DN". In the picture below, it shows the uid=root at the bottom.

However, later on when you edit the configuration.yml file for Authelia, under authentication_backend -> ldap -> user: you put "uid=admin". Shouldn't it be "uid=root" as per your previous picture? I bolded and underlined the reference I'm making below.

authentication_backend:
ldap:
implementation: custom
url: ldap://yourNASIP
start_tls: false
base_dn: dc=blackvoid,dc=home # enter the values from the LDAP config
groups_filter: (&(uniquemember={dn})(objectclass=groupOfUniqueNames))
user: uid=admin,cn=users,dc=blackvoid,dc=home # your LDAP parameters
password: xxxxxxxxxxx # LDAP Admin password

2) I made it to almost the end of your guide, but I cannot sign in to Authelia app. I get an "Incorrect username or password" red message from the app. I can get the login page, but I cannot login properly. As per portainer, the error log shows the following:

time="2021-05-17T02:02:05Z" level=error msg="Error while checking password for user admin: Cannot find user DN of user admin. Cause: LDAP Result Code 32 \"No Such Object\": " method=POST path=/api/firstfactor remote_ip=172.17.0.1 stack="github.com/authelia/authelia/internal/middlewares/authelia_context.go:65 (*AutheliaCtx).Error\ngithub.com/authelia/authelia/internal/handlers/response.go:148 handleAuthenticationUnauthorized\ngithub.com/authelia/authelia/internal/handlers/handler_firstfactor.go:103 FirstFactorPost.func1\ngithub.com/authelia/authelia/internal/middlewares/authelia_context.go:50 AutheliaMiddleware.func1.1\ngithub.com/fasthttp/[email protected]/router.go:414 (*Router).Handler\ngithub.com/authelia/authelia/internal/middlewares/log_request.go:14 LogRequestMiddleware.func1\ngithub.com/valyala/[email protected]/server.go:2219 (*Server).serveConn\ngithub.com/valyala/[email protected]/workerpool.go:223 (*workerPool).workerFunc\ngithub.com/valyala/[email protected]/workerpool.go:195 (*workerPool).getCh.func1\nruntime/asm_amd64.s:1371 goexit",

time="2021-05-17T02:02:35Z" level=debug msg="Mark authentication attempt made by user root" method=POST path=/api/firstfactor remote_ip=172.17.0.1 time="2021-05-17T02:02:35Z" level=error msg="Error while checking password for user root: Cannot find user DN of user root. Cause: LDAP Result Code 32 \"No Such Object\": " method=POST path=/api/firstfactor remote_ip=172.17.0.1 stack="github.com/authelia/authelia/internal/middlewares/authelia_context.go:65 (*AutheliaCtx).Error\ngithub.com/authelia/authelia/internal/handlers/response.go:148 handleAuthenticationUnauthorized\ngithub.com/authelia/authelia/internal/handlers/handler_firstfactor.go:103 FirstFactorPost.func1\ngithub.com/authelia/authelia/internal/middlewares/authelia_context.go:50 AutheliaMiddleware.func1.1\ngithub.com/fasthttp/[email protected]/router.go:414 (*Router).Handler\ngithub.com/authelia/authelia/internal/middlewares/log_request.go:14 LogRequestMiddleware.func1\ngithub.com/valyala/[email protected]/server.go:2219 (*Server).serveConn\ngithub.com/valyala/[email protected]/workerpool.go:223 (*workerPool).workerFunc\ngithub.com/valyala/[email protected]/workerpool.go:195 (*workerPool).getCh.func1\nruntime/asm_amd64.s:1371

I triple checked my LDAP password and its a very very long 85 digit password I made with Bitwarden. it doesn't show the username on the Synology LDAP server page, but I'm assuming it's either admin or root. I tried using either username but neither worked. I can't login.

Any advice, or what I may be missing on this?

 

[Herry1988]

Thank you! It is helpful!

 

[Rusty]

Shouldn't it be "uid=root" as per your previous picture?

It can be both.

Root pass is the password on the main LDAP screen. Admin pass is configured on the User tab for that admin account.

I get an "Incorrect username or password" red message from the app. I can get the login page, but I cannot login properly

Be sure to set the correct password in the config file depending if you are going as root or admin. I would suggest using the admin account and its password (configured in LDAP separately!).

Also be sure to check if you have made this change in order to resolve the users from Syno LDAP:

## The username and password of the admin user.                                                                                                               
    user: uid=admin,cn=users,dc=blackvoid,dc=home                                                                                                                 
    ## Password can also be set using a secret: https://www.authelia.com/docs/configuration/secrets.html                                                         
    password: xxxxxxxxxxxxxxxxxxxxx

So this user line is not by default. By default it looks like this:

 ## The username and password of the admin user.
    user: cn=admin,dc=example,dc=com
    ## Password can also be set using a secret: https://www.authelia.com/docs/configuration/secrets.html
    password: password

Make note that the user account needs to be changed from cn to uid, otherwise you will not resolve the user. If this is set, then be sure, as I said already, to check the user/password combination on your LDAP side as well as in your config file.

 

[Rusty]

Also just made a comparison between my config and the original config file.

There are 2 more lines that need to be changed a bit to make this work with Syno LDAP and it could be a reason for your problem:

line 158: change it to cn=users
line 178: change it to cn=groups

Give that a go and see.

 

[Bogey]

Hi Rusty,

Thank you for your awesome guides! Consice, yet enough details to get it working instantly

Regarding Authelia in combo with Ngingx Proxy Manager I have a question:
I've set up myapp.mydomain.com with a 2fa for traffic from internet and with 1fa from internal.
I expected that the following would work...

access_control:
  default_policy: deny
    networks:
    - name: internal
      networks:
        - 192.168.0.0/24

  rules:
    - domain:
        - auth.mydomain.com
      policy: bypass

    - domain: myapp.mydomain.com
      policy: one_factor
      networks:
        - internal

    - domain: myapp.mydomain.com
      policy: two_factor

However, it does not work, because in the log of Authelia I see that my home computer (192.168.0.100) is presented with the external IP. So when I change 192.168.0.0/24 to 86.91.xxx.xx then it works.

This would not be a problem if I would have a fixed IP address. Unfortunately that's not the case, so when my external IP address changes I have to manually adjust configuration.yml and change the internal IP address.

The solution is probably in change something in NPM's "Custom Nginx Configuration"... but I don't know what.
Can you help?

Thanks,
Eddie

Edit: in docker auth.mydomain.com (authilia) is on 172.17.0.0/16 network (default bridge right?) and myapp.mydomain.com is on a different network: 172.18.0.0/16.

NPM's myapp.mydomain.com "Custom Nginx Configuration" 3rd line from the bottom reads:
set_real_ip_from 172.17.0.0/16; # change the subnet to match your own
Authelia's log file shows 86.91.xxx.xx as 'real IP' -- my external IP address.

Do I change it to:
set_real_ip_from 172.18.0.0/16; # change the subnet to match your own
Then Authelia log file shows 172.17.0.1 as 'real IP' -- what correctly can be marked as 'internal' though be it a docker network.
Also when I change it to 192.168.0.0./24 then too 172.17.0.1 is shown as 'real IP' -- it's always the docker bridge's IP address.

 

[Rusty]

Hi Rusty,

Thank you for your awesome guides! Consice, yet enough details to get it working instantly

Regarding Authelia in combo with Ngingx Proxy Manager I have a question:
I've set up myapp.mydomain.com with a 2fa for traffic from internet and with 1fa from internal.
I expected that the following would work...

access_control:
  default_policy: deny
    networks:
    - name: internal
      networks:
        - 192.168.0.0/24

  rules:
    - domain:
        - auth.mydomain.com
      policy: bypass

    - domain: myapp.mydomain.com
      policy: one_factor
      networks:
        - internal

    - domain: myapp.mydomain.com
      policy: two_factor

However, it does not work, because in the log of Authelia I see that my home computer (192.168.0.100) is presented with the external IP. So when I change 192.168.0.0/24 to 86.91.xxx.xx then it works.

This would not be a problem if I would have a fixed IP address. Unfortunately that's not the case, so when my external IP address changes I have to manually adjust configuration.yml and change the internal IP address.

The solution is probably in change something in NPM's "Custom Nginx Configuration"... but I don't know what.
Can you help?

Thanks,
Eddie

Edit: in docker auth.mydomain.com (authilia) is on 172.17.0.0/16 network (default bridge right?) and myapp.mydomain.com is on a different network: 172.18.0.0/16.

NPM's myapp.mydomain.com "Custom Nginx Configuration" 3rd line from the bottom reads:
set_real_ip_from 172.17.0.0/16; # change the subnet to match your own
Authelia's log file shows 86.91.xxx.xx as 'real IP' -- my external IP address.

Do I change it to:
set_real_ip_from 172.18.0.0/16; # change the subnet to match your own
Then Authelia log file shows 172.17.0.1 as 'real IP' -- what correctly can be marked as 'internal' though be it a docker network.
Also when I change it to 192.168.0.0./24 then too 172.17.0.1 is shown as 'real IP' -- it's always the docker bridge's IP address.

Hey there!

tnx for the positive comments and glad you got it going in the end.

About your question. I have set set_real_ip_from 172.18.0.0/16; # change the subnet to match your own to my real LAN subnet, not the Docker one in any case.

Also when I change it to 192.168.0.0./24 then too 172.17.0.1 is shown as 'real IP' -- it's always the docker bridge's IP address.

This is because NPM is running in docker network that is bridged, not host, so the realIP is not resolving as it should. The point is that regardless of Authelia, if you don't have NPM presenting as "bare metal" install, you will not be able to get real ip resolution to work (unlike the built-in nginx on your NAS that runs as bare metal).

 

[Bogey]

Hey there!

tnx for the positive comments and glad you got it going in the end.

About your question. I have set set_real_ip_from 172.18.0.0/16; # change the subnet to match your own to my real LAN subnet, not the Docker one in any case.


This is because NPM is running in docker network that is bridged, not host, so the realIP is not resolving as it should. The point is that regardless of Authelia, if you don't have NPM presenting as "bare metal" install, you will not be able to get real ip resolution to work (unlike the built-in nginx on your NAS that runs as bare metal).

Thanks for your fast reply, I appreciate it!

So the solution would be to change NPM's network_mode: "bridge" to network_mode: "host" AND set_real_ip_from of ALL (Authelia and the apps) to the real LAN subbet?

 

[Rusty]

Thanks for your fast reply, I appreciate it!

So the solution would be to change NPM's network_mode: "bridge" to network_mode: "host" AND set_real_ip_from to the real LAN subbet?

That would be a solution, but you will not be able to push NPM to host as it will try to set itself on ports 80 and 443, and those are already in use by the built in one.

You need to configure NPM on a device/platform that will allow you to use those ports. One option is a VM with docker inside it and host your NPM there.

 

[Bogey]

Rusty, do you think a macvlan can be used (instead of a VM)?

 

[Rusty]

Rusty, do you think a macvlan can be used (instead of a VM)?

It can but you will not be able to use that container running with macvlan to talk to the docker host or any other container in bridge on that same host. Limitation of how docker networking works.

 

[Bogey]

I've read about that in one of your other comments.
Do you have a blog post where the (dis)advantages of each docker network is explained in regards to Synology?
I've noticed that quite a few containers require different settings for Docker on Synology than other machines.

 

[Rusty]

I've read about that in one of your other comments.
Do you have a blog post where the (dis)advantages of each docker network is explained in regards to Synology?
I've noticed that quite a few containers require different settings for Docker on Synology than other machines.

No, I don't have an article on that because this is not really a question of Docker Vs Syno. In this particular case, it might look that way but in general, it is more how Docker networks work in general and this macvlan limitation is Docker specific. It would apply the same way if you were running docker on a non Syno device as well.

 

[Bogey]

No, I don't have an article on that because this is not really a question of Docker Vs Syno. In this particular case, it might look that way but in general, it is more how Docker networks work in general and this macvlan limitation is Docker specific. It would apply the same way if you were running docker on a non Syno device as well.

Gotcha!
Thanks Rusty.

 

[wiredworm]

I've come across this post whilst trying to find a solution to an issue i've got.

I've got an instance of SWAG running which integrates with Authelia. Unfortunately the policy i've created for the internal network doesn't work as expected and looking at the logs it looks like the problem is to do with the address that is being forwarded from the SWAG instance. Both SWAG and Authelia run as Docker containers so I suspect the address shown (172.17.0.1) is from the Docker network.

I've seen various posts that contain fragments like this:

set_real_ip_from 172.17.0.0/16;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

But, the problem for me is that i'm not quite sure where the above code needs to be placed. I've found documentation for other proxies but in this case i'm using SWAG so I could really use a hand in finding out where to play the adjustments to make sure the correct IP is passed into Authelia.

Any help that can be offered would be greately appreciated.

 

[wiredworm]

I managed to figure this out in the end. I added these lines to the location block in the default file found in nginx/site-confs:

set_real_ip_from 172.17.0.0/16;
real_ip_header X-Forwarded-For;

I also had to follow this guide to make some changes to ipTables. This solved the issue.