Send netdisco-users mailing list submissions to
netdisco-users@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/netdisco-users
or, via email, send a message with subject or body 'help' to
netdisco-users-requ...@lists.sourceforge.net
You can reach the person managing the list at
netdisco-users-ow...@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netdisco-users digest..."
Today's Topics:
1. Re: X-REMOTE_USER not being passed to Dancer (Christian Ramseyer)
--- Begin Message ---
Hi
On 19.03.2025 06:39, Michael Butash wrote:
So I've been setting up oauth2-proxy to hide the apps I run on the
server alongside netdisco, and getting around to trying this too now
having seen this discussion recently. It's still failing with the
patched version of DBIC.pm Christian provided unfortunately.
I did enable log (I think, tried a few ways to define it), but I never
see any helpful output when connecting, mostly relying on watching the
unencrypted port 5000 traffic to see the headers are being passed when
feeding my cookie and session.
T 127.0.0.1:49686 <http://127.0.0.1:49686> -> 127.0.0.1:5000
<http://127.0.0.1:5000> [AP] #140
GET /netdisco/debug HTTP/1.0.
X-REMOTE_USER: mbut...@domain.com.
Host: scazrnetmon.domain.local.
X-Real-IP: 10.0.0.16.
X-Forwarded-For: 10.0.0.16.
X-Forwarded-Proto: https.
A side note first: If in your nginx/oauth-proxy you have netdisco in
/netdisco, make sure to also set web_home to /netdisco
<https://github.com/netdisco/netdisco/wiki/Configuration#web_home> if
you haven't already, otherwise this might add random issues on top of
the login problem.
I'm learning a whole lot more about web authentication than I ever
wanted to in the past few days, I'm open to testing anything to get
this working.
Already it's been weird using nginx+oauth2-proxy as nginx hates
underscores in your choice in the X-REMOTE_USER field, and finally
working around that even push the header. It would be nice if I could
change that to use the header already being returned by oauth2/Entra
as X-Auth-Request-Preferred-Username or X-Auth-Request-Email that both
return email-format username.
When enabling the remote user features, while debugging it, it seems
to break normal local users from logging in then, which is less than
ideal as a fall-back account to get in it regardless of Entra status.
Can we allow for both remote AND local, or at least provide an option
to do so (I can see NOT wanting this for security in some cases)?
Yes this feature is a bit bare-bones, it would be nice if:
* the name of the header could be configured
* Netdisco doesn't really have groups but there should also be a
header to toggle the admin and portctl properties for an user via proxy
Unfortunately this is currently not the case, and once trust_ is set
normal logging also seems to be disabled. In the current state, you'd
need a second web process with it's own config to have user/pw Login there.
Now assuming this works, does this still present the chicken and egg
problem of having to add the user to be able to authenticate first?
This is what validate_remote_user does: if it's false, the user is just
assumed to be in the database with default permissions and it doesn't
really need to exists. Unfortunately there is no way to specify other
permissons than default for this case currently.
Is there any possibility of adding a group match layer? All in all
I've got 4 apps on this box, librenms, grafana, prometheus, and
netdisco, of which I have the simplest, prometheus working fine with
with the oauth2 redirect and callback to the sites each fine, but
passing the group for grafana/librenms/netdisco is the bonus round now
to differentiate admin vs non-admin. Grafana and Librenms supposedly
do it (though after about 8 hours of fiddling with grafana this
weekend I can't figure it out, librenms is tbd...), it would be nice
if Netdisco could eventually dynamically add users and match their
group returned via some Group header as well.
Yes group match would be great I agree, but currently not implemented.
The closest you could get is using validate_remote_user: false and then
create users only for the people that don't have default permissions.
The only good news I have for you is that the "base case" seems to work
for me, even with a @domain in the username. E.g.:
ramseyer@test:~/ndd101 $ grep -i remote_user apache/httpd.conf
SetEnv REMOTE_USER "adm...@netnea.com"
RequestHeader set X-REMOTE_USER "%{REMOTE_USER}e"
ramseyer@test:~/ndd101 $ docker-compose exec netdisco-postgresql psql -U
postgres netdisco -c "select * from users where username ~* 'adminx'"
username | password | creation
| last_on | port_control | ldap | admin | fullname | note | token
| token_from | radius | tacacs | portctl_role
----------+---------------------------------------------------------------------+----------------------------+---------+--------------+------+-------+----------+------------+-------+------------+--------+--------+--------------
adminx |
{CRYPT}$2a$04$/0sS6uR84QMpxVPhb6W8hOy6JfD1g.rlkdaeMndtBgkn1pvKyuGLy |
2025-03-15 12:39:11.492099 | | f | f | t
| | pw: adminx | | | f | f |
(1 row)
ramseyer@test:~/ndd101 $ grep remote netdisco/config/deployment.yml
trust_x_remote_user: true
validate_remote_user: true
With these, I'm getting logged in as adminx. Surprisingly it does not
work when setting the record to username = 'adm...@netnea.com', it looks
like the domain is truncated somewhere in the Dancer/plack layer. It
also work for random username strings that are not in the DB when
setting validate_remote_user: false.
If this part still doesn't work for you, here are commands how you can
start the web server in the foreground with some tracing enabled:
https://github.com/netdisco/netdisco/wiki/Developing#tldr-i-just-want-to-clone-the-repo-and-get-started
- this might allow you to see where it goes wrong.
Cheers
Christian
Thanks as always!
-mb
On Sat, Mar 15, 2025 at 6:29 AM Christian Ramseyer
<ramse...@netnea.com> wrote:
Hi Michael
Yes I tried something similar once and also had the impression this
didn't work properly. I've played around some more now and
attempted a fix:
https://github.com/netdisco/netdisco/pull/1310
It would be great if you could take the DBIC.pm file from there
and see
if it works for you? Watch out there's two DBIC.pm, more precisely
it's
lib/App/Netdisco/Web/Auth/Provider/DBIC.pm that has the change.
Cheers
Christian
On 11.03.2025 18:53, Michael Dano wrote:
> We are working to set up SAML login via Apache Reverse Proxy to do
> authentication. We have the X-REMOTE_USER being populated with
the user
> name from Entra ID. We have verified that the X-REMOTE_USER
value is
> being sent to Dancer in the header. We did use the Dancer Debug
sidebar
> to verify that the value is accurate. We do not see any login
attempts
> into the Netdisco site from the user. In the deployment.yml file
we have
> the values set as:
>
> auth_user_env: "X-REMOTE_USER"
> trust_x_remote_user: true
> validate_remote_user: true
>
> We have verified that the user exists in Netdisco but never see any
> authentication attempts come in. Is there additional
configuration that
> needs to be done on the deployment.yml side to allow the user to
> authenticate?
--
Christian Ramseyer, netnea ag
Network Management. Security. OpenSource.
https://www.netnea.com
Phone: +41 79 644 77 64
_______________________________________________
Netdisco mailing list
netdisco-users@lists.sourceforge.net
https://sourceforge.net/p/netdisco/mailman/netdisco-users/
--
Christian Ramseyer, netnea ag
Network Management. Security. OpenSource.
https://www.netnea.com
Phone: +41 79 644 77 64
--- End Message ---
_______________________________________________
Netdisco mailing list - Digest Mode
netdisco-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netdisco-users
