[bravetraveler]

Certainly! In this case, they were interested in files that were too permissive.

I don't have a good example of the command, but it was basically looking for 'worldly' permissions that were too open. It's important to note the users/groups could be discarded/ignored.

They were using 'find ... -exec ls -ld {} \;', which does an LDAP lookup on each result to resolve UIDs and GIDs to names.

They could have made the process far more efficient with either the native '-ls' argument built into find, or adding '-n' to the exec'd 'ls'

Either would skip the name resolution/domain. At a certain number of results/files the expense is too high, causing the job to time out

[res0nat0r]

I think correctly configuring nscd should prevent this, ie it should cache some of these name lookups for a period of time. As long as it is properly setup for LDAP to hook into it.

https://linux.die.net/man/8/nscd

[bravetraveler]

I suspect you're right, I'm not as familiar with our configuration (or the service) as I'd like to be

The 'ls' output is honestly superfluous, though - 'find' will report the paths.

I won't even get into how these are batched/time limited. If not this, it'd be something else eventually

[eddd-ddde]

Conincidentaly I just found a book in the office on understanding and deploying ldap directory services, seems like today is gonna be spent reading!

[bravetraveler]

Best of luck to you! I've been around them for over a decade now, and still can't commit the various services to memory.

I like to call what I do "taking the coward's way out" -- using FreeIPA

My team setup the infrastructure in question and I've been too slow to learn it. FreeIPA is nice for quick/easy deployments.

I'm not sure how well it "scales", but it's great for getting comfortable with the "Domain Language" (sorry, pun)

[TheNewsIsHere]

Sounds like a spectacular self-DDoS on your LDAP infrastructure if that thing ever got deployed too widely and ran at the same time everywhere.