Here’s a way to automate the download of data from Active Directory (AD), specifically group members, into ACL using adfind and the ACL Execute command.
I’ll walk you through it step-by-step.
This was posted before ACL released their own Active Directory driver, which I still haven’t figured out.
Even if you don’t use ACL, you might gain a better understanding of AD and LDAP in general….
If you’re looking for an insightful server audit, and you’re dauntless, you might want to jump on this train.
First, why do you need to be dauntless?
Because you’re going to need to obtain your data from a number of different sources; the bigger your company, the more likely you’ll need to call on and question more than a handful of people.
Because comparing and tracking all the servers that are on one list, but not another can be a challenge.
Because it his highly LIKELY that you WILL find something and the server team will not be happy.
When checking system access, make sure you look at all the different items that affect the user’s access. For example, the user might need one or more of the following:
- Application ID
- Application role or group
- Membership in an local server group, Active Directory (AD) group, or UNIX Group
- Access to the application’s share and/or folder on the server
- Database ID
- Database role, including access permissions (read/write)
- Other permission (from a home-grown application code or enterprise identify management system)
I’m getting discouraged. I’m starting to wonder how many audit departments follow auditing standards, say, from IIA or ISACA. After some of the IT audits and IT SOX audits I’ve seen in the past year, who knows.
Some companies take their control owner words as gold and don’t verify them.
“They wouldn’t give you the information if it wasn’t true! Audit the evidence you’re given and quit questioning everything!” said one audit director. Excuse me, but doesn’t ISACA requires auditors to maintain their professional skepticism. Perhaps ISACA means be skeptical of audit directors?