AD/AAD and VPN integration
-
@stacksofplates said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@stacksofplates said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@irj said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@scottalanmiller said in AD/AAD and VPN integration:
Ask it another way.... so you want to expose your AD infrastructure and fragility directly to the Internet? AD isn't meant to ever see light of day, the entire design of AD is that it is protected inside the LAN. If you do this, you are disabling the foundation of AD's security.
I can understand where you're coming from - I'll even go so far as to say I agree, at least to some point.
But the extra oneous on end users is what is trying to be avoided. I guess your answer to that is - tough, suck it up, this is security we're talking about here, and security is basically the antithesis of convenience?
The thing is you're not exposing your AD with SAML authentication. Worse case scenario a malicious user can spoof a session. MFA does alot to alleviate this concern, but even MFA isn't perfect.
Plenty of other ways to secure SAML or verify your IDP and service provider like azure has them in place.
https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html
Even really basic stuff like IP filtering is helpful when authenticating SAML to a SaaS service. The attacker would have to know the IP range of SaaS application. Again not a save all security measure, but it helps more than you'd think.
Also short authentication timeouts with need to re
-authenticate in 15 or 30 mins when not in use is also a huge help.I don't understand how SAML isn't exposing your AD/AAD authentication?
Isn't it the same username/password for SAML as it is for AD/AAD?
So let's assume a logon to M365 with MFA, let's also assume there is federation between your local AD and AAD.... So you log into M365 and it shows you on the screen that it's waiting for MFA verification - when you see that you KNOW you have the correct username and password for AD/AAD... right?
If you're concerned with SAML then use openid connect with the authorization code flow. The users creds are never passed through the portal and an access token is generated. Then apps can verify user authorization through a JWT token.
I have literally zero clue what you just said.
How does what you just said apply to a user getting on their home laptop and logging into M365? or nearly any web portal?
User creds are never passed to the system with the authorization code flow.
OpenID Connect uses the same model as SAML so there is no difference there. It's called HTTP redirect binding in SAML. SAML can be setup in other ways too but that is what is commonly used.
Either way, the users password are never sent to or even known by the service you're connecting to.
-
@pete-s yeah, it's actually pretty slick tech.
-
@stacksofplates said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@stacksofplates said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@irj said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@scottalanmiller said in AD/AAD and VPN integration:
Ask it another way.... so you want to expose your AD infrastructure and fragility directly to the Internet? AD isn't meant to ever see light of day, the entire design of AD is that it is protected inside the LAN. If you do this, you are disabling the foundation of AD's security.
I can understand where you're coming from - I'll even go so far as to say I agree, at least to some point.
But the extra oneous on end users is what is trying to be avoided. I guess your answer to that is - tough, suck it up, this is security we're talking about here, and security is basically the antithesis of convenience?
The thing is you're not exposing your AD with SAML authentication. Worse case scenario a malicious user can spoof a session. MFA does alot to alleviate this concern, but even MFA isn't perfect.
Plenty of other ways to secure SAML or verify your IDP and service provider like azure has them in place.
https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html
Even really basic stuff like IP filtering is helpful when authenticating SAML to a SaaS service. The attacker would have to know the IP range of SaaS application. Again not a save all security measure, but it helps more than you'd think.
Also short authentication timeouts with need to re
-authenticate in 15 or 30 mins when not in use is also a huge help.I don't understand how SAML isn't exposing your AD/AAD authentication?
Isn't it the same username/password for SAML as it is for AD/AAD?
So let's assume a logon to M365 with MFA, let's also assume there is federation between your local AD and AAD.... So you log into M365 and it shows you on the screen that it's waiting for MFA verification - when you see that you KNOW you have the correct username and password for AD/AAD... right?
If you're concerned with SAML then use openid connect with the authorization code flow. The users creds are never passed through the portal and an access token is generated. Then apps can verify user authorization through a JWT token.
I have literally zero clue what you just said.
How does what you just said apply to a user getting on their home laptop and logging into M365? or nearly any web portal?User creds are never passed to the system with the authorization code flow.
oh - I'm not worried about things like yelp in this case.... I'm worried about a hacker having the Google username/password in your example.
-
@gjacobse said in AD/AAD and VPN integration:
twenty-two minimum and going to a one year cycle.
OMG - everyone will quit.
Why not go to keycards instead. Jesus...
-
@pete-s said in AD/AAD and VPN integration:
@stacksofplates said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@stacksofplates said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@irj said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@scottalanmiller said in AD/AAD and VPN integration:
Ask it another way.... so you want to expose your AD infrastructure and fragility directly to the Internet? AD isn't meant to ever see light of day, the entire design of AD is that it is protected inside the LAN. If you do this, you are disabling the foundation of AD's security.
I can understand where you're coming from - I'll even go so far as to say I agree, at least to some point.
But the extra oneous on end users is what is trying to be avoided. I guess your answer to that is - tough, suck it up, this is security we're talking about here, and security is basically the antithesis of convenience?
The thing is you're not exposing your AD with SAML authentication. Worse case scenario a malicious user can spoof a session. MFA does alot to alleviate this concern, but even MFA isn't perfect.
Plenty of other ways to secure SAML or verify your IDP and service provider like azure has them in place.
https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html
Even really basic stuff like IP filtering is helpful when authenticating SAML to a SaaS service. The attacker would have to know the IP range of SaaS application. Again not a save all security measure, but it helps more than you'd think.
Also short authentication timeouts with need to re
-authenticate in 15 or 30 mins when not in use is also a huge help.I don't understand how SAML isn't exposing your AD/AAD authentication?
Isn't it the same username/password for SAML as it is for AD/AAD?
So let's assume a logon to M365 with MFA, let's also assume there is federation between your local AD and AAD.... So you log into M365 and it shows you on the screen that it's waiting for MFA verification - when you see that you KNOW you have the correct username and password for AD/AAD... right?
If you're concerned with SAML then use openid connect with the authorization code flow. The users creds are never passed through the portal and an access token is generated. Then apps can verify user authorization through a JWT token.
I have literally zero clue what you just said.
How does what you just said apply to a user getting on their home laptop and logging into M365? or nearly any web portal?User creds are never passed to the system with the authorization code flow.
OpenID Connect uses the same model as SAML so there is no difference there. It's called HTTP redirect binding in SAML. SAML can be setup in other ways too but that is what is commonly used.
Either way, the users password are never sent to or even known by the service you're connecting to.
The flow is similar but the data model is different. OIDC uses an encoded and signed JWT with claims. This makes integrations much easier because it doesn't rely on XML and SOAP.
-
@dashrender said in AD/AAD and VPN integration:
@stacksofplates said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@stacksofplates said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@irj said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@scottalanmiller said in AD/AAD and VPN integration:
Ask it another way.... so you want to expose your AD infrastructure and fragility directly to the Internet? AD isn't meant to ever see light of day, the entire design of AD is that it is protected inside the LAN. If you do this, you are disabling the foundation of AD's security.
I can understand where you're coming from - I'll even go so far as to say I agree, at least to some point.
But the extra oneous on end users is what is trying to be avoided. I guess your answer to that is - tough, suck it up, this is security we're talking about here, and security is basically the antithesis of convenience?
The thing is you're not exposing your AD with SAML authentication. Worse case scenario a malicious user can spoof a session. MFA does alot to alleviate this concern, but even MFA isn't perfect.
Plenty of other ways to secure SAML or verify your IDP and service provider like azure has them in place.
https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html
Even really basic stuff like IP filtering is helpful when authenticating SAML to a SaaS service. The attacker would have to know the IP range of SaaS application. Again not a save all security measure, but it helps more than you'd think.
Also short authentication timeouts with need to re
-authenticate in 15 or 30 mins when not in use is also a huge help.I don't understand how SAML isn't exposing your AD/AAD authentication?
Isn't it the same username/password for SAML as it is for AD/AAD?
So let's assume a logon to M365 with MFA, let's also assume there is federation between your local AD and AAD.... So you log into M365 and it shows you on the screen that it's waiting for MFA verification - when you see that you KNOW you have the correct username and password for AD/AAD... right?
If you're concerned with SAML then use openid connect with the authorization code flow. The users creds are never passed through the portal and an access token is generated. Then apps can verify user authorization through a JWT token.
I have literally zero clue what you just said.
How does what you just said apply to a user getting on their home laptop and logging into M365? or nearly any web portal?User creds are never passed to the system with the authorization code flow.
oh - I'm not worried about things like yelp in this case.... I'm worried about a hacker having the Google username/password in your example.
You don't seem to get the point. This doesn't have anything to do with Yelp other than that was the example in the image.
OIDC is a way to use properly designed IdPs. The VPN provider can use a properly designed IdP that doesn't have to be internal to authorize the user and the VPN provider never needs to know the users credentials.
-
@stacksofplates said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@stacksofplates said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@stacksofplates said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@irj said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@scottalanmiller said in AD/AAD and VPN integration:
Ask it another way.... so you want to expose your AD infrastructure and fragility directly to the Internet? AD isn't meant to ever see light of day, the entire design of AD is that it is protected inside the LAN. If you do this, you are disabling the foundation of AD's security.
I can understand where you're coming from - I'll even go so far as to say I agree, at least to some point.
But the extra oneous on end users is what is trying to be avoided. I guess your answer to that is - tough, suck it up, this is security we're talking about here, and security is basically the antithesis of convenience?
The thing is you're not exposing your AD with SAML authentication. Worse case scenario a malicious user can spoof a session. MFA does alot to alleviate this concern, but even MFA isn't perfect.
Plenty of other ways to secure SAML or verify your IDP and service provider like azure has them in place.
https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html
Even really basic stuff like IP filtering is helpful when authenticating SAML to a SaaS service. The attacker would have to know the IP range of SaaS application. Again not a save all security measure, but it helps more than you'd think.
Also short authentication timeouts with need to re
-authenticate in 15 or 30 mins when not in use is also a huge help.I don't understand how SAML isn't exposing your AD/AAD authentication?
Isn't it the same username/password for SAML as it is for AD/AAD?
So let's assume a logon to M365 with MFA, let's also assume there is federation between your local AD and AAD.... So you log into M365 and it shows you on the screen that it's waiting for MFA verification - when you see that you KNOW you have the correct username and password for AD/AAD... right?
If you're concerned with SAML then use openid connect with the authorization code flow. The users creds are never passed through the portal and an access token is generated. Then apps can verify user authorization through a JWT token.
I have literally zero clue what you just said.
How does what you just said apply to a user getting on their home laptop and logging into M365? or nearly any web portal?User creds are never passed to the system with the authorization code flow.
oh - I'm not worried about things like yelp in this case.... I'm worried about a hacker having the Google username/password in your example.
You don't seem to get the point. This doesn't have anything to do with Yelp other than that was the example in the image.
OIDC is a way to use properly designed IdPs. The VPN provider can use a properly designed IdP that doesn't have to be internal to authorize the user and the VPN provider never needs to know the users credentials.
Awww - you're sticking to the OP - (which is good
) I was only really thinking about website logons, Not VPN access.yes, you're solutions look good for allowing the use of AD/AAD as the source of authentication without exposing it to the outside.
-
@dashrender said in AD/AAD and VPN integration:
@stacksofplates said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@stacksofplates said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@stacksofplates said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@irj said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@scottalanmiller said in AD/AAD and VPN integration:
Ask it another way.... so you want to expose your AD infrastructure and fragility directly to the Internet? AD isn't meant to ever see light of day, the entire design of AD is that it is protected inside the LAN. If you do this, you are disabling the foundation of AD's security.
I can understand where you're coming from - I'll even go so far as to say I agree, at least to some point.
But the extra oneous on end users is what is trying to be avoided. I guess your answer to that is - tough, suck it up, this is security we're talking about here, and security is basically the antithesis of convenience?
The thing is you're not exposing your AD with SAML authentication. Worse case scenario a malicious user can spoof a session. MFA does alot to alleviate this concern, but even MFA isn't perfect.
Plenty of other ways to secure SAML or verify your IDP and service provider like azure has them in place.
https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html
Even really basic stuff like IP filtering is helpful when authenticating SAML to a SaaS service. The attacker would have to know the IP range of SaaS application. Again not a save all security measure, but it helps more than you'd think.
Also short authentication timeouts with need to re
-authenticate in 15 or 30 mins when not in use is also a huge help.I don't understand how SAML isn't exposing your AD/AAD authentication?
Isn't it the same username/password for SAML as it is for AD/AAD?
So let's assume a logon to M365 with MFA, let's also assume there is federation between your local AD and AAD.... So you log into M365 and it shows you on the screen that it's waiting for MFA verification - when you see that you KNOW you have the correct username and password for AD/AAD... right?
If you're concerned with SAML then use openid connect with the authorization code flow. The users creds are never passed through the portal and an access token is generated. Then apps can verify user authorization through a JWT token.
I have literally zero clue what you just said.
How does what you just said apply to a user getting on their home laptop and logging into M365? or nearly any web portal?User creds are never passed to the system with the authorization code flow.
oh - I'm not worried about things like yelp in this case.... I'm worried about a hacker having the Google username/password in your example.
You don't seem to get the point. This doesn't have anything to do with Yelp other than that was the example in the image.
OIDC is a way to use properly designed IdPs. The VPN provider can use a properly designed IdP that doesn't have to be internal to authorize the user and the VPN provider never needs to know the users credentials.
Awww - you're sticking to the OP - (which is good
) I was only really thinking about website logons, Not VPN access.yes, you're solutions look good for allowing the use of AD/AAD as the source of authentication without exposing it to the outside.
And to Pete's point, SAML has the same flow. It's just a different payload.
-
@dashrender said in AD/AAD and VPN integration:
@stacksofplates said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@stacksofplates said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@stacksofplates said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@irj said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@scottalanmiller said in AD/AAD and VPN integration:
Ask it another way.... so you want to expose your AD infrastructure and fragility directly to the Internet? AD isn't meant to ever see light of day, the entire design of AD is that it is protected inside the LAN. If you do this, you are disabling the foundation of AD's security.
I can understand where you're coming from - I'll even go so far as to say I agree, at least to some point.
But the extra oneous on end users is what is trying to be avoided. I guess your answer to that is - tough, suck it up, this is security we're talking about here, and security is basically the antithesis of convenience?
The thing is you're not exposing your AD with SAML authentication. Worse case scenario a malicious user can spoof a session. MFA does alot to alleviate this concern, but even MFA isn't perfect.
Plenty of other ways to secure SAML or verify your IDP and service provider like azure has them in place.
https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html
Even really basic stuff like IP filtering is helpful when authenticating SAML to a SaaS service. The attacker would have to know the IP range of SaaS application. Again not a save all security measure, but it helps more than you'd think.
Also short authentication timeouts with need to re
-authenticate in 15 or 30 mins when not in use is also a huge help.I don't understand how SAML isn't exposing your AD/AAD authentication?
Isn't it the same username/password for SAML as it is for AD/AAD?
So let's assume a logon to M365 with MFA, let's also assume there is federation between your local AD and AAD.... So you log into M365 and it shows you on the screen that it's waiting for MFA verification - when you see that you KNOW you have the correct username and password for AD/AAD... right?
If you're concerned with SAML then use openid connect with the authorization code flow. The users creds are never passed through the portal and an access token is generated. Then apps can verify user authorization through a JWT token.
I have literally zero clue what you just said.
How does what you just said apply to a user getting on their home laptop and logging into M365? or nearly any web portal?User creds are never passed to the system with the authorization code flow.
oh - I'm not worried about things like yelp in this case.... I'm worried about a hacker having the Google username/password in your example.
You don't seem to get the point. This doesn't have anything to do with Yelp other than that was the example in the image.
OIDC is a way to use properly designed IdPs. The VPN provider can use a properly designed IdP that doesn't have to be internal to authorize the user and the VPN provider never needs to know the users credentials.
Awww - you're sticking to the OP - (which is good
) I was only really thinking about website logons, Not VPN access.yes, you're solutions look good for allowing the use of AD/AAD as the source of authentication without exposing it to the outside.
Oauth2 is used on alot of web applications. Here's a good saml vs oauth2 comparison.
-
@irj said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@stacksofplates said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@stacksofplates said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@stacksofplates said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@irj said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
@scottalanmiller said in AD/AAD and VPN integration:
Ask it another way.... so you want to expose your AD infrastructure and fragility directly to the Internet? AD isn't meant to ever see light of day, the entire design of AD is that it is protected inside the LAN. If you do this, you are disabling the foundation of AD's security.
I can understand where you're coming from - I'll even go so far as to say I agree, at least to some point.
But the extra oneous on end users is what is trying to be avoided. I guess your answer to that is - tough, suck it up, this is security we're talking about here, and security is basically the antithesis of convenience?
The thing is you're not exposing your AD with SAML authentication. Worse case scenario a malicious user can spoof a session. MFA does alot to alleviate this concern, but even MFA isn't perfect.
Plenty of other ways to secure SAML or verify your IDP and service provider like azure has them in place.
https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html
Even really basic stuff like IP filtering is helpful when authenticating SAML to a SaaS service. The attacker would have to know the IP range of SaaS application. Again not a save all security measure, but it helps more than you'd think.
Also short authentication timeouts with need to re
-authenticate in 15 or 30 mins when not in use is also a huge help.I don't understand how SAML isn't exposing your AD/AAD authentication?
Isn't it the same username/password for SAML as it is for AD/AAD?
So let's assume a logon to M365 with MFA, let's also assume there is federation between your local AD and AAD.... So you log into M365 and it shows you on the screen that it's waiting for MFA verification - when you see that you KNOW you have the correct username and password for AD/AAD... right?
If you're concerned with SAML then use openid connect with the authorization code flow. The users creds are never passed through the portal and an access token is generated. Then apps can verify user authorization through a JWT token.
I have literally zero clue what you just said.
How does what you just said apply to a user getting on their home laptop and logging into M365? or nearly any web portal?User creds are never passed to the system with the authorization code flow.
oh - I'm not worried about things like yelp in this case.... I'm worried about a hacker having the Google username/password in your example.
You don't seem to get the point. This doesn't have anything to do with Yelp other than that was the example in the image.
OIDC is a way to use properly designed IdPs. The VPN provider can use a properly designed IdP that doesn't have to be internal to authorize the user and the VPN provider never needs to know the users credentials.
Awww - you're sticking to the OP - (which is good
) I was only really thinking about website logons, Not VPN access.yes, you're solutions look good for allowing the use of AD/AAD as the source of authentication without exposing it to the outside.
Oauth2 is used on alot of web applications. Here's a good saml vs oauth2 comparison.
OIDC adds the authentication layer on top of Oauth2 which was just the authorization layer. It's good to understand the differences between all three solutions.
-
@dafyre said in AD/AAD and VPN integration:
I can't quote much on the VPN side of things, but we use MFA here for nearly everything now.
Duo Security (duo.com) is great. You can use hardware keys or the app on your phone, and it's quick and easy enough to manage.
Edit: Even our VPN now requires MFA, lol.
Not everything supports Duo, though, such as WHfB unless you go through another IDP that does support it.
