[_8j50]

So, on that, it is surprisingly difficult to get rid of hard coded credentials and funnily vendors like tychotic and hashicorp are supposed to prevent that by having some api thing that integrates with scripts.

That said, tychotic,cyberark and pals that manage credentials almost always need domain admin. I think just moving to full AAD and azure key vault might be better but realistically this is the nature of the beast. If I had to guess the "network share" is probably a GPO on a DC that is used by tychotic, anything short of that is ridiculously bad. GPOs are shared to all machines so they can be pushed to them so you see creds in there sometimes if scripts need them, the thinking being "if the bad guys are in the network we have bigger issues" (again with the perimeter centric intuitive security mindset).

[spydum]

the cute answer to all this is always: how do people think your service accesses the secret vault? its anlther credential.

the real issues are tougher, like why does this one cred have access to all these other creds, and how or if they were auditing usage of that cred from authorized client devices.. but all of these problems take a lot of effort and care to solve. and as history has shown, you only have to mess up once.

[_8j50]

I agree but an api key for a PAM service will get you constrained access (ideally) to a specific resource instead of a kerberos ticket you can take with you as part of your ticket collection. It's supposed to be better but granting the resource permission like GCP does is probably better (but messier too).

[spydum]

for sure; the real failure in this setup was again, having a single credential with access to so many other critical secrets. I have yet to see a secret vault that had good analytics for this kind of thing - it assumes you have designed your secret hierarchy and permissions appropriately.

ideally, there would be a warning for identities with access to too many secrets.