AD/AAD and VPN integration
-
It's interesting how Microsoft's doing passwords these days.
I'm not sure what the actual requirements are, but shorter, 8'ish character long, seem to be the minimum, but they won't allow the use of passwords that are found to be the leaked password lists, as well as other obviously easy to guess options.
In deploying M365 recently - it was funny how many people got the - We've seen that password to many times - please choose another
-
@dashrender said in AD/AAD and VPN integration:
@scottalanmiller said in AD/AAD and VPN integration:
The old system was designed to make passwords easy for the computer, hard for the humans. THe humans are the fragile part, not the computers.
While the reality of that statement is true - I'm sure it wasn't the design - i.e. make it easier for computers....
Moving to Long non complex passwords is definitely a huge step in the right direction...
It absolutely was. And intentionally. But not in 1999. It was more like 1980 when processing passwords was actually a computational problem. That started trends in "how to make a password had for a computer to guess" while "still able to be looked up and encrypted." Short passwords were necessary, that's why UNIX had an eight character limit for so long - computational power.
We couldn't consider doing modern, good password practice until those systems that demanded super short passwords were phased out.
-
@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.
-
@scottalanmiller said in AD/AAD and VPN integration:
That's nota good pattern for security.
No joke - A passphrase is better. And I suggest using that when doing user training. Twelve is the minimum - Again - there is plans being set down for nearly a complete dirt up rebuild. We are replacing poorly implemented hardware and security. One suggestion is about a twenty-two minimum and going to a one year cycle.
-
@gjacobse said in AD/AAD and VPN integration:
@scottalanmiller said in AD/AAD and VPN integration:
That's nota good pattern for security.
One suggestion is about a twenty-two minimum and going to a one year cycle.
-
@gjacobse said in AD/AAD and VPN integration:
@scottalanmiller said in AD/AAD and VPN integration:
That's nota good pattern for security.
No joke - A passphrase is better. And I suggest using that when doing user training. Twelve is the minimum - Again - there is plans being set down for nearly a complete dirt up rebuild. We are replacing poorly implemented hardware and security. One suggestion is about a twenty-two minimum and going to a one year cycle.
In a Server 2008 R2 functional level domain environment, the longest minimum password you can set it 14, IIRC.
-
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.
-
@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.
