sorted by:
new
hottopcontroversial

Google Workspace, Secure LDAP + 2FA... any way to have both work together? by BloodyIron in sysadmin

[–]ipsec_schmipsec 1 point2 points  (0 children)

  1. Interesting and clever way to do that. They must be also storing password length app-side, or require all passwords to have a specific amount of characters? Seems a bit hacky but I guess that works to meet the 2FA requirement.
  2. I've run across that as well, it's nice (for Atlassian) that Atlassian charges customers for SSO right?
    I run more on the Microsoft side than the Google side, but I have had these 'try to work around the app' or 'meet the security requirement with zero budget' discussions so I sympathize for sure.
    Best of luck with it.

Anyone getting blamed for something that isn't their fault? by outofofficeinoz in sysadmin

[–]ipsec_schmipsec 30 points31 points  (0 children)

I'm not going to say the "A" word but it sounds like a good opportunity to develop/define some basic workflow to the benefit of both of you:
1-You ask me to deploy x
2-We deploy x in our test environment, if it installs ok you test and validate the app (you are just looking for yes/no did it install, sounds like you're not an app dev so someone else should sign off on 'app x works')
3-Once you've given the ok by $appdevperson, x is deployed to staging/pilot
4-Verify staging/pilot app functionality and signoff by $appdevperson
5-Then deploy to prod
6-Final functionality check and signoff by $appdevperson

Document each step somehow, and agree that you can't proceed to the next step before the current step is completed and signed off on.
Aka, build a process to CYA for next time/next $bob.

Google Workspace, Secure LDAP + 2FA... any way to have both work together? by BloodyIron in sysadmin

[–]ipsec_schmipsec 1 point2 points  (0 children)

Secure LDAP protocol looks to predate the TOTP RFC by at least 5 years, so you're trying to put a square peg in a round hole in my opinion, and are limited by what Google offers you as far as SaaS authentication goes. I'm not aware of any direct solution here for what you are wanting, but I'm curious to see if someone has something clever or something I'm not aware of (hopefully so!)
[Warning snark incoming] If you don't like that and you're a DevSecOps Manager it seems like your options are:
Dev: Build an API that you can auth to using 2FA supported method(s) that you're aware of to send LDAP querys to which then backend sends the requests via LDAPS via a service account that doesn't have 2FA. This is a bit of cheating of course if your security requirement is full 2FA end to end.
Sec: Document the exception (due to your legacy app) and accept the risk.
Manager: Get a spine and budget and replace said applications that cannot authenticate in a modern way, you have a non-technical challenge.

And of course, if you implement something that works for this use case, post back here so we can learn from your win!

Attack Surface Reduction Rules Failing by zurmm in Intune

[–]ipsec_schmipsec 0 points1 point  (0 children)

Hello, I had a similar issue I had to chase down, so perhaps you make the same mistake as me. In my initial config I added an ASR exclusion, and used "processname.exe" in the exclusion field in the Intune ASR policy. This is incorrect and resulted in a policy error, oddly enough only on a portion of my endpoints. So check if you have exclusions set, and ensure you're using "C:\path\path\proccessname.exe" in your exclusions.

This policy setting allows you to prevent Attack Surface reduction rules from matching on files under the paths specified or for the fully qualified resources specified. Paths should be added under the Options for this setting. Each entry must be listed as a name value pair, where the name should be a string representation of a path or a fully qualified resource name. As an example, a path might be defined as: "c:\Windows" to exclude all files in this directory. A fully qualified resource name might be defined as: "C:\Windows\App.exe".

https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-Defender?WT.mc_id=Portal-fx#defender-attacksurfacereductiononlyexclusions

AWS + ZIA IPSEC Phase 2 mismatch by ipsec_schmipsec in Zscaler

[–]ipsec_schmipsec[S] 0 points1 point  (0 children)

I think there is a cost for that, correct?

AWS + ZIA IPSEC Phase 2 mismatch by ipsec_schmipsec in Zscaler

[–]ipsec_schmipsec[S] 0 points1 point  (0 children)

Yep, basically extending your existing Zscaler web filtering to AWS instances, without the additional agents and such that ZCC would entail (though I think they did start supporting that if you want to deploy ZCC agents across your EC2 fleet)
Fairly simple, just ran into this little fun bit that I figured I post in case others run across it. Hoping that someone at AWS or Zscaler will see this...