@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.

https://www.okta.com/identity-101/saml-vs-oauth/

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.

@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:

@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.

@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:

@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.

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:

@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.

Plus even with things like openshift, kubevirt is doing any KVM work for you. You need 0 KVM expertise to let Kubernetes manage your hypervisor/VMs.

@pete-s said in KVM or VMWare:

@stacksofplates said in KVM or VMWare:

@pete-s said in KVM or VMWare:

@stacksofplates said in KVM or VMWare:

@pete-s said in KVM or VMWare:

@stacksofplates said in KVM or VMWare:

@irj said in KVM or VMWare:

@irj said in KVM or VMWare:

@stacksofplates said in KVM or VMWare:

The integration with the REST APIs is more important than any of the anscillary features of qemu/libvirt.

Exactly. Stuff isn't done manually anymore.

It's not even that about manual process. It's about being able audit, and have a repeatable process.

Auditing in KVM is pretty much not there lol.

Just a side note, but what type of auditing are you talking about? Security audit? Compliance audit?

All of the above.

OK, thanks.

But how about libvirt being used by openstack and openshift? There has to be a lot of enterprises running that in their hybrid cloud environment. Surely not everyone is running their workloads only on Amazon or Google. Red Hat has to be out there pushing a lot of this to their enterprise customers. And surely these environments are fully automated and auditable just like aws or gcp. Or isn't that the case?

I don't know anyone running RHEV. I also don't know anyone actually running openatack. I'm sure there are a few but it's hardly the norm.

Openshift may use libvirt underneath with kubevirt but I think most are just running containers. I don't know too many places running openshift either over just k8s.

There are 4000+ jobs on linkedin in the US when searching for openstack.
8000+ jobs when searching for openshift. And I see companies such as Bank of America, Citi, Delta Air Lines, Federal Reserve etc. So I'm guessing it's in use for sure.

That's not really that many positions. And that's not a great metric because a lot are most likely repeats and are possibly just anscillary tech knowledge. "Must understand hypervisors: VMware, openstack, xenserver, etc"

I'm not saying they aren't used but they aren't popular.

Edit because openatack isn't a thing.

Here's one example of why KVM isnt more popular than it is. I love how KVM does snapshotting. I can create thousands of snapshots off of a metadata preallocated qcow2 image because it's reallocate on write and not copy on write. You would incur almost no performance hit up to a few thousand snapshots. But who works that way anymore? If you have the experience to automate reallocated snapshots and block commit them back to the base, you have the expertise to just create ephemeral systems and not use snapshots at all. Then you turn your expertise to automation of more important things. It's good at what it does, but when you have the expertise to leverage it at that level, you don't need it anymore.

@pete-s said in KVM or VMWare:

@stacksofplates said in KVM or VMWare:

@pete-s said in KVM or VMWare:

@stacksofplates said in KVM or VMWare:

@irj said in KVM or VMWare:

@irj said in KVM or VMWare:

@stacksofplates said in KVM or VMWare:

The integration with the REST APIs is more important than any of the anscillary features of qemu/libvirt.

Exactly. Stuff isn't done manually anymore.

It's not even that about manual process. It's about being able audit, and have a repeatable process.

Auditing in KVM is pretty much not there lol.

Just a side note, but what type of auditing are you talking about? Security audit? Compliance audit?

All of the above.

OK, thanks.

But how about libvirt being used by openstack and openshift? There has to be a lot of enterprises running that in their hybrid cloud environment. Surely not everyone is running their workloads only on Amazon or Google. Red Hat has to be out there pushing a lot of this to their enterprise customers. And surely these environments are fully automated and auditable just like aws or gcp. Or isn't that the case?

I don't know anyone running RHEV. I also don't know anyone actually running openatack. I'm sure there are a few but it's hardly the norm.

Openshift may use libvirt underneath with kubevirt but I think most are just running containers. I don't know too many places running openshift either over just k8s.

@irj said in KVM or VMWare:

@stacksofplates said in KVM or VMWare:

@stacksofplates said in KVM or VMWare:

@scottalanmiller said in KVM or VMWare:

think

That's not apples to apples. One is support one is hiring engineers. Two different things.

No idea why this quoted so weird.

"Just because something may be supported, doesn't imply that it is support."

@pete-s said in KVM or VMWare:

@stacksofplates said in KVM or VMWare:

@irj said in KVM or VMWare:

@irj said in KVM or VMWare:

@stacksofplates said in KVM or VMWare:

The integration with the REST APIs is more important than any of the anscillary features of qemu/libvirt.

Exactly. Stuff isn't done manually anymore.

It's not even that about manual process. It's about being able audit, and have a repeatable process.

Auditing in KVM is pretty much not there lol.

Just a side note, but what type of auditing are you talking about? Security audit? Compliance audit?

All of the above.

@stacksofplates said in KVM or VMWare:

@scottalanmiller said in KVM or VMWare:

think

That's not apples to apples. One is support one is hiring engineers. Two different things.

No idea why this quoted so weird.

@scottalanmiller said in KVM or VMWare:

think

That's not apples to apples. One is support one is hiring engineers. Two different things.

@irj said in KVM or VMWare:

@irj said in KVM or VMWare:

@stacksofplates said in KVM or VMWare:

The integration with the REST APIs is more important than any of the anscillary features of qemu/libvirt.

Exactly. Stuff isn't done manually anymore.

It's not even that about manual process. It's about being able audit, and have a repeatable process.

Auditing in KVM is pretty much not there lol.

@scottalanmiller said in KVM or VMWare:

From working in big business, if I was to use my small cross section of things, I'd say that VMware support is truly lacking in comparison to KVM.

Atatements like this are what make people not listen to things you say. This is just clearly not the case.

@scottalanmiller said in KVM or VMWare:

@stacksofplates said in KVM or VMWare:

@scottalanmiller said in KVM or VMWare:

@stacksofplates said in KVM or VMWare:

@scottalanmiller said in KVM or VMWare:

There's no shortage of KVM talent, so anyone telling you that they can't hire is actually telling you that they are so bad at searching that they can't function as a business or they are so bad to work for that no amount of money can fix it.

This simply isn't true. No one in the enterprise space runs qemu/libvirt. They've developed their own APIs (gvisor, firecracker, etc).

It's totally true. Just because you are talking to companies doing a bad job and lying about it and you are accepting what they say as truth doesn't make it so, at all. As long as talent is on the market, and it is without any shortage, then the issue is with the companies hiring (or failing to hire), this is just basic logic. They claim they can't hire, yet people are looking for that work that know what they are doing. GIven those facts, what they claim can't be true. Basic economics.

I'm not. You don't have a real pulse on the market it seems. These are just claims you're making without any basis. Just because you can find some people who can install Proxmox doesn't mean there is KVM expertise.

Also, Proxmox doesn't count as KVM expertise in case that's the angle you're trying to use here.

I never made the claim about anything about ProxMox. I just said that KVM skills are not in short supply. There's lots on the market. Everyone makes claims that there is a shortage to justify not providing in house talent and just going to vendors. It's an easy claim to make and if a company is crap at hiring it even makes it appear to be true. But we all work in IT and know that it's not even remotely true. Tons of people are on the market, and tons of support firms are too. The bottom line is that companies avoid hiring them (or anyone) because they like just paying a vendor as an excuse. Went through this this week, luckily once we talked about this exact stuff they understood immediately and didn't just hire a vendor to sell them stuff.

It's easy to follow the sales people and get paid as a middleman and not to do IT, so everyone wants to so it. Big enterprises are full of middle managers looking to protect their jobs. SO the process just keeps repeating. But don't repeat it to IT people as if we don't know better. We all know that skills are on the market and companies aren't hiring them.

Point to any consultancy other than yourself that specializes in KVM. You continually say things like "we know", "every one knows", "it's clear" but never provide any proof.

Libvirt and qemu clearly aren't used widely and it shows in their APIs. You can say vmware is because of sales people but people writing the automation around these solutions make it clear that it isn't. Tools like VMware and even nutanix to a degree are the most widely used because it's much much easier to integrate with them.

I love KVM and love to use it but there is clearly not a lot of KVM talent running around.

@scottalanmiller said in KVM or VMWare:

@stacksofplates said in KVM or VMWare:

@scottalanmiller said in KVM or VMWare:

There's no shortage of KVM talent, so anyone telling you that they can't hire is actually telling you that they are so bad at searching that they can't function as a business or they are so bad to work for that no amount of money can fix it.

This simply isn't true. No one in the enterprise space runs qemu/libvirt. They've developed their own APIs (gvisor, firecracker, etc).

It's totally true. Just because you are talking to companies doing a bad job and lying about it and you are accepting what they say as truth doesn't make it so, at all. As long as talent is on the market, and it is without any shortage, then the issue is with the companies hiring (or failing to hire), this is just basic logic. They claim they can't hire, yet people are looking for that work that know what they are doing. GIven those facts, what they claim can't be true. Basic economics.

I'm not. You don't have a real pulse on the market it seems. These are just claims you're making without any basis. Just because you can find some people who can install Proxmox doesn't mean there is KVM expertise.

Also, Proxmox doesn't count as KVM expertise in case that's the angle you're trying to use here.

The enterprises that don't use KVM with their own APIs/emulator (or run fully cloud) run VMware for the APIs. The integration with the REST APIs is more important than any of the anscillary features of qemu/libvirt.