lithnet / access-manager

Access Manager provides web-based access to local admin (LAPS) passwords, BitLocker recovery keys, and just-in-time administrative access to Windows computers in a modern, secure, and user-friendly way.
Other
238 stars 20 forks source link

[FEAT] Add the ability to log out. #204

Closed Wolfhound905 closed 1 year ago

Wolfhound905 commented 1 year ago

Is your feature request related to a problem? Please describe. I am confused by the login. I log in with my AD credentials, and then I'm in. There is no way to log out, there are no cookies that contain the login or anything. This leads me to belive that the system is IP based, since mac addresses can be spoofed.

Describe the solution you'd like There needs to be a clear way to log out of the service and end your session.

Wolfhound905 commented 1 year ago

Ok, so I just read this issue https://github.com/lithnet/access-manager/issues/67

Are you serious? Wontfix? This seems like such a bad authentication system. What kind of weird system are you guys using?! The browser should not be able to just make its own session. When the cookies are cleared, that client needs to authenticate. You may have to rewrite the login shit because this honestly is making me wonder if this should stay in our environment.

ryannewington commented 1 year ago

Hi @Wolfhound905,

Integrated windows authentication is indeed not great (it's a 90s auth protocol), and its why there are limitations on it use, and we don't recommend it for production use.

IWA isn't implemented by our app, it's negotiated between the browser, and the server's windows HTTP.sys stack. In order to use IWA, our app needs to tell HTTP.sys that it should challenge browsers for IWA.

When a client makes a connection to the HTTP server, HTTP.sys will tell the browser it needs to auth, and that the server accepts windows auth. The browser will then negotiate windows auth with the server. Once that negotiation is successful, windows passes the resulting windows access token to the app. There's no cookies or sessions involved from the app perspective.

The browser will continue to send the negotiated authentication header. There is nothing the server or app can do to tell the browser not to send it. Even if there was a session cookie or something to clear on the server side, the next request the browser made, would contain the IWA logon information, and a 'new' session would be created automatically.

It doesn't use IP or mac address, it's using the Kerberos or NTLM credentials the user signed into windows with.

This isn't an Access Manager specific issue

You'll see the same behavior in other places where IWA is used

As a side note, IWA is no longer supported with HTTP/2+ https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10/http2-on-iis#when-is-http2-not-supported

I'm happy to provide any additional information you'd like, or answer any further questions, but I'd request we keep the tone respectful.

Wolfhound905 commented 1 year ago

Sorry, I don't know why I was so rude in my comment. Thank you for more clarification.

I can see now if I reset the browser it prompts me to re-log in. It is just very interesting how the login works, and I thought it was insecure at first.

ryannewington commented 1 year ago

No problems mate.

Yep, by modern standards, it's not very intuitive, and doesn't work the way we expect modern auth to work. We had a long debate as to if we even support it in the product. We decided to include it because it is useful for rapid prototyping/proof of concepts, and there are some legitimate use cases where customers want to publish it behind things like AzureAD reverse proxy, which can handle the kerberos stuff safely.

Feel free to reach out if there is anything else we can help with.