To start out, the "security tab" of a user account enumerates the permissions on that account, not the permissions that the account has in the environment. Understanding this very basic principle is crucial for a person who will be charged with attempting to penetrate Active Directory and identify and understand vulnerabilities in particular implementations.
Another item that is crucial to understand is that Active Directory itself is not a central repository of permissions. That is, while there are a lot of WHOs and WHATs in Active Directory, it is not a database of WHO has access to WHAT (outside of the actual database objects themselves. While it can be used to provide this information, it requires that it be designed and managed precisely with that goal in mind, and a strict adherence to maintaintenance; however, this is not commonly the case.
As you are going to be performing penetration tests, you will likely be attempting to perform these tests in various environments whose composition, structure and organization are outside of your control, you will frequently encounter the directory that is not maintained as such.
Each resource has its own ACL. Moreover, we're not just speaking of ACLs on file shares, but also directory objects, printers, file systems, etc. These accounts can also be members of local groups (as previously mentioned), and can be delegated User Rights on member computers -- not to mention specific file system permission entries on member computers which are not otherwise directly exposed by file shares. Access to hypervisors, storage devices, switches, firewalls, and other networking gear could also be controlled by Active Directory authentication.
That does not even get into the scope of access in trusted forests, LDAP-authenticated applications (like internal web services or applications), databases, federated logons, etc.
So, essentially, the answer to your question is generally, one can't (easily) enumerate a complete list of all access granted to a particular user account, and I would argue that it is likely outside the scope of pentesting Active Directory anyway.