AD/AAD and VPN integration
-
@scottalanmiller said in AD/AAD and VPN integration:
@gjacobse said in AD/AAD and VPN integration:
Using AD/AAD, what is a recommendation of a VPN solution?
To not do it. This takes all of the risks of VPN, and all of the risks that people associated with RDP, and combines them for the ultimate in disaster.
so the preference is to manage a user sign on twice?
-
@gjacobse said in AD/AAD and VPN integration:
@scottalanmiller said in AD/AAD and VPN integration:
@gjacobse said in AD/AAD and VPN integration:
Using AD/AAD, what is a recommendation of a VPN solution?
To not do it. This takes all of the risks of VPN, and all of the risks that people associated with RDP, and combines them for the ultimate in disaster.
so the preference is to manage a user sign on twice?
That's what provides the safety of having the VPN. If you remove that, you are crippling the security functions.
-
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.
-
@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?
-
Don't get me wrong here, I understand the need for security, physical and electronic. But you also need to consider the user base, Doctors and Nurses. Yes they are bright enough to deal with all of the medical shy-nola but ask them to log into a shared phone with a four digit extension and four digit pass code is akin to driving behind someone at 7am where the speed limit is 55mph and they can't do more than 40mph.... It's a straight road, conditions are normal and there is no one in front of you for a mile.... Drive the speed limit or park it.
There has to be a better way that doesn't compromise security but doesn't require a blood sacrifice.
-
@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. -
A little more about how this network is built -
Turns out the FW appliance 'should' be able to connect to AD - but can't due to a known firmware issue. And from the story I was told - it was
put in placewith a known firmware issue.The pre-dates the current Director, IT Lead, Infrastructure Eng and myself. The Infrastructure Eng wouldn't have allowed it, and while he's impressed - he's impressed only by the fact of just how Janky F-Up things are.
We are on the way to
UN-F things. There is a huge re-structure / configuration on the near horizon with an office move, office renovation and opening of an additional clinic... While I think the Co-lo is 'okay' our main data store will be completely replaced... As it was built janky and left... -
@irj said in AD/AAD and VPN integration:
but even MFA isn't perfect
Ha - is that the truth. MS SMS MFA was down a while earlier this week...
-
@gjacobse said in AD/AAD and VPN integration:
@irj said in AD/AAD and VPN integration:
but even MFA isn't perfect
Ha - is that the truth. MS SMS MFA was down a while earlier this week...
I wouldn't even consider SMS viable MFA for internal employees. Maybe for external users because they won't install MFA app.
-
@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?
Right, making things "so easy" for end users if taken to the extreme results in open connections, no security, no login. Anyone that goes to the service gets in. Obviously, no one is going to do that. But that's where we head. AD and regular Windows security is pretty weak and minimal, but enough to stop a normal attacker. It's adequate, just barely. But if we take AD from its minimally viable stance and extend it to be massively (meaning orders of magnitude) more exposed, that minimal stance becomes an "absurdly insecure" stance. Or, if we lock it down hard, "heavily unstable".
-
@gjacobse said in AD/AAD and VPN integration:
Don't get me wrong here, I understand the need for security, physical and electronic. But you also need to consider the user base, Doctors and Nurses. Yes they are bright enough to deal with all of the medical shy-nola but ask them to log into a shared phone with a four digit extension and four digit pass code is akin to driving behind someone at 7am where the speed limit is 55mph and they can't do more than 40mph.... It's a straight road, conditions are normal and there is no one in front of you for a mile.... Drive the speed limit or park it.
There has to be a better way that doesn't compromise security but doesn't require a blood sacrifice.
Holy crap, if you did this with doctors and nurses I think this moves from simply being reckless to it actually being illegal. I doubt that any HIPAA compliant shop or worker could consider this. This absolutely violates professional requirements, it should violate any medical ones. I understand that doctors and nurses are at the very least capable ranges typically and need less security than a McDonald's cashier in most cases but at some point they aren't legally capable of doing their jobs and you should not be taking risks on their behalf because they are incompetent.
-
@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?
-
@gjacobse said in AD/AAD and VPN integration:
Don't get me wrong here, I understand the need for security, physical and electronic. But you also need to consider the user base, Doctors and Nurses. Yes they are bright enough to deal with all of the medical shy-nola but ask them to log into a shared phone with a four digit extension and four digit pass code ...
I don't think this is a good example.
How is this any different than logging into the computer as themselves? Let me guess - they all have passwordless keycards they use to access their computers?If they are mobile users and want their own assigned extension to ring to them.. how else would they expect it to work?
-
@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.
