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 (Michael Dano)
--- Begin Message ---
I was able to get my configuration working. My issue was in my
deployment.yml file. I needed to remove the line that contained auth_user_env:
"X-REMOTE_USER" from the deployment.yml file. We are not sure if it's a
leftover from the conversions and updates over the years or got added on
accident. That coupled with the fact we are sending an additional claim
value and assigning that to the X-REMOTE_USER to match the Netdisco
username. Everything is now working correctly
Since we have Netdisco set to trust_x_remote_user: true and
validate_remote_user: true I have found that the port control and admin
setting in Netdisco are applied to the user as appropriate to the setting
applied to that user inside Netdisco. As Christian said we have found that
once the trust user is set true local login no longer works, but as long as
you have a user or two with the admin settings applied in Netdisco they
should retain those settings even when they Auth through Entra.
To handle the fact that a user must exist in Netdisco prior to being able
to Auth through Entra we created a script years ago, that is currently tied
to ldap but being converted, that injects the usernames and setting into
the Postgresql DB. We then have that script run as a cron job on the server
to update users based on the AD groups we are using.
[image: Baker College Logo]
Mike Dano
*Senior System Administrator*Infrastructure Security & Support
mdan...@baker.edu
O: (989) 729-3917
M: (810) 650-0947
[image: Further Together]
baker.edu
On Wed, Mar 19, 2025 at 10:38 AM Christian Ramseyer <ramse...@netnea.com>
wrote:
> 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 -> 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" <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
