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.
-
Then apps can use OPA to validate any other authorization you need based on claims in the JWT and AD groups. Decouple the authorization from the applications themselves and then your authorization profiles can be reused across your infrastructure.
-
@dashrender said in AD/AAD and VPN integration:
Let me guess - they all have passwordless keycards they use to access their computers?
No - all users use a AD userID and Password, password required is at least twelve: upper.lower.number.symbol on 90day cycle.
-
@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? -
-
@gjacobse said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
Let me guess - they all have passwordless keycards they use to access their computers?
No - all users use a AD userID and Password, password required is at least twelve: upper.lower.number.symbol on 90day cycle.
OK - so that's how you explain the logging into a phone - this is just like your computer, only it's your phone so YOU can get YOUR calls at THIS phone.
Now, if they don't need their own extension to follow them, then the phone just has whatever extension is assigned to it.
-
@gjacobse said in AD/AAD and VPN integration:
@dashrender said in AD/AAD and VPN integration:
Let me guess - they all have passwordless keycards they use to access their computers?
No - all users use a AD userID and Password, password required is at least twelve: upper.lower.number.symbol on 90day cycle.
That's nota good pattern for security. That is exactly what puts passwords at risk. It makes them hard to remember (for humans) and the 90 day cycle guarantees that no normal human can ever commit them to memory so they are forced to write them down!!
That's why good security has never allowed that pattern and eventually, after a decade of fighting, the NIST finally said it wasn't good either and admitted that the industry standard of long, easy to remember, not so complex (for humans) passwords that rarely change is far, far more secure.
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.
-
@irj said in AD/AAD and VPN integration:
https://docs.microsoft.com/en-us/azure/active-directory/develop/single-sign-on-saml-protocol
HAHAHAHAHA
that is doing exactly what I said - user is typing in the username and password - then the MFA prompt.... so a hacker who doesn't have MFA device will at least KNOW they have the correct username/password combo when they see the waiting for MFA notice.
-
@dashrender said in AD/AAD and VPN integration:
@irj said in AD/AAD and VPN integration:
https://docs.microsoft.com/en-us/azure/active-directory/develop/single-sign-on-saml-protocol
HAHAHAHAHA
that is doing exactly what I said - user is typing in the username and password - then the MFA prompt.... so a hacker who doesn't have MFA device will at least KNOW they have the correct username/password combo when they see the waiting for MFA notice.
Did you even look at the article?
-
@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'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.
