According to the two TechNet articles below, a user with the ‘take ownership’ permission on a file or folder should be able to assign ownership to a group of which they’re a member. Unfortunately, it doesn’t seem to work that way.  An error is thrown indicating that the user should have ‘restore files and directories’ permission in order to assign ownership to a group.

http://technet.microsoft.com/en-us/library/cc753659.aspx
http://technet.microsoft.com/en-us/library/cc780020(WS.10).aspx

Thanks! to FK for raising the issue (which contradicts information in the NetVision paper on Windows Access Rights)  It’s a fairly obscure find, but worth understanding.

Windows file system permissions are complicated enough without having to consider file shares.  But, we use shares because they make life easier in networked environments.  So, we need to understand how Windows file share permissions affect the effective rights that users have to files and folders.  The Security permissions tab doesn’t tell the whole story.

Sometimes, we run into scenarios where an account appears to have been granted access to appropriate groups, but when the user tries to access an important file, she is denied access.  Other times, it’s the reverse scenario. Again, users appear to have been granted appropriate group memberships, but they are actually able to access more than they should.  And of course it’s almost never obvious why we get these unexpected results.

When configuring a Windows file share, the permissions for the share are handled differently than the rights granted on the file system itself. Each share has its own ACE (Access Control Entry) that governs the permissions on the file system to which the share enables access. Since both direct assignments and share assignments have their own ACEs, Microsoft provides a simple rule on how these ACEs will work together. When both affect the same area of the file system, the most restrictive of the two permission sets has precedence. Sounds simple. But in practice, determining how direct and share permissions cause unexpected effective rights for users can be complicated and time consuming.

Complicating things further, users are sometimes directly granted permissions to a share or file system rather than having permissions assigned via group memberships. And accounts can belong to numerous groups that each has different sets of permissions. As this web of permissions is constructed from multiple sources of permission assignments, the job of determining how accounts have gained or lost access gets increasingly complicated.

NetVision takes the mystery out of Access Rights. It’s critical to be able to easily and quickly determine the effective rights to sensitive data. NetVision’s Access Rights Inspector allows users to gather file system rights information, and then display the effective rights applied to users and groups across the file system.

Instead of limiting our scope to explicit rights across a file system (ACE entries), NetVision reports on permissions acquired from all sources - explicit permissions, shares, ownership, group memberships, etc. Access Rights Inspector makes all permission settings clear and provides a quick view into the calculated effective rights saving time, reducing cost, and improving your security posture.

When files and folders are created on the Windows file system, an owner is assigned to that object.  By default, the owner is the creator of the file.  But, ownership can be re-assigned by the current owner or system administrators. When assigning an owner, it’s critical to understand what the attribute means. 

A file or folder owner always has the rights to adjust permissions.  So, even if everyone is denied rights and the owner account can no longer view the document, it can still be used to adjust permissions to grant itself (or anyone else) any additional permissions.

In most cases, an explicit deny rule takes precedence over other rights assignments. In the case of owner, however, this is not true.  So, ownership needs to be considered when looking at what file permissions are assigned.

The implicit rights granted by the owner attribute take precedence over all other permissions, including denies.

To ensure proper access to files on the Windows file system, NetVision’s ARI accounts for the owner of a file system object when calculating effective rights. This allows users to be able to locate accounts that may have more privileges than expected because they are set as the owner of a file or folder. If a user is set as the owner and their effective permissions also allow them to browse or see the file or folder, then they can grant other rights to see items in the folder and below. If you don’t want users to be able to change permissions on files and folders, then you need to ensure that they’re not set as the owner. The owner attribute in most cases should be set to an administrative group so only appropriately privileged accounts can change these permissions.

Here’s a link to our Active Directory UserAccountControl Quick Reference Guide.  It’s not intended to be a complete reference on the UserAccountControl attribute, but rather a quick reference for common values related to Access Rights.

It includes things like checking for password not required, password set to not expire, disabled accounts, and smart card required.

Here’s a link to our Windows File System Permissions Quick Reference guide.  It gives you the permissions as labelled in the Windows Security dialog and then lists how that permission affects both folders and files.  In most cases, permissions are applied slightly differently depending on whether the object is a file or folder.

One method of monitoring possible inappropriate access attempts to Active Directory is to watch for Failed Logon attempts.  One way to do that is to monitor specific events in the Security Event Log on ALL servers within an environment.  The challenge with this has always been trying to monitor and gather all the appropriate information across all systems within an environment.

NetVision has greatly simplified this by centralizing the effort and applying filters at the event source that allow the system to gather only appropriate data and act upon the event information according to pre-defined rules (record it, write to file, send an alert, etc.)

NetVision reports on the following types of Failed Logons:

1. Failed Logon attempts to the Local System
2. Failed Logon because an account is Disabled
3. Failed Logon because an account is Expired
4. Failed Logon because an account is Locked
5. Failed Logon because of Machine Restrictions
6. Failed Logon because of an accounts Password is Expired
7. Failed Logon because of a Time Restriction
8. Failed Logon because of an account Type Restriction
9. Failed Logon because an account is Unknown

NetVision allows you to gather and process ALL Failed Logons centrally so you can evaluate the events, build appropriate reports, and take action on possibly inappropriate behaviors within your environment.

UPDATED: We can also track and report on failed logon attempts without relying on the security event log, making it easy to capture and report on a subset of users (such as system administrators) without having to store ALL failed logon attempts across the enterprise.  …forgot to mention that in the original post.

If you’re trying to audit the Last Logoff time of users in Active Directory or to programmaticly confirm whether someone is still logged on, your intuition might tell you to monitor the lastLogoff attribute. Unfortunately, you’d be wrong.

Active Directory does provide a User object attribute named lastLogoff where logoff Information should theoretically be stored. However, Microsoft currently does NOT utilize this attribute to store logoff information.  [more info on that]

In order to monitor User logoff activity on your own, you would need to watch the Security Event Log at every DC.  And you’d need to configure the Security Event Log policy on each relevant server to monitor logoff events. You would also also need to ensure that the event logs aren’t being overwritten before you capture the information (which can be tricky in large environments if you’re capturing all logon and logoff activity).  And you would have no ability to filter the events so that you’re getting only relevant information.

Because Microsoft doesn’t update Active Directory information during a logoff event, NetVision also monitors the event logs to capture logoff events.  But, because we’re already installed, there’s nothing else you need to do.  And we give you the ability to filter events based on what’s important to you (such as limiting Logoff events to a particular subset of Users).  The resulting reports are easy to read, exportable, and stored independent of logs so they’ll never get overwritten.

Note: Monitoring Logoff events is never 100% reliable. This blog entry from the Windows auditing team explains why.

NetVision customers often ask for help reporting on the last time a particular user logged onto the network.  Here’s what you need to know about finding the right attributes.

Active Directory
When querying for Last logon, a very common mistake is to look at the LastLogonTimeStamp attribute.  If this attribute is selected, no data will be returned.  It’s a calculated attribute that doesn’t hold information.  The correct attribute to query is LastLogon.  This attribute contains the last time the user logged into AD. 

NOTE: If you’re filtering in real-time for specific users, be careful.  The person logging in will NOT show as the UserID, it will show as the system process used in authenticating the user.  To correctly monitor for specific accounts, NetVision customers can set your filter to include the list of accounts you are interested in monitoring.  When the LastLogon attribute is written to AD, the object (or DN) that receives the attribute change is what NetVision records.  If the policy is set correctly, you will see the change to the LastLogon time and you will be able to see the system process that authenticated the user or object.

eDirectory
When querying for last logon in eDirectory, a common mistake is to select the lastLoginTime attribute.  If this attribute is selected, the date and time that will be returned is not the true last time the user logged in, but the time before.  For example, If I logged in on 1/5/09 at 8am, and then logged in again on 2/8/09 at 9am, the lastLoginTime attribute will have the value of 1/5/09 8am (a full month off).  The correct attribute to query is loginTime.  This entry contains the true last time the user logged into eDirectory.

 Got Other Challenges Like This?
The roles and usage of the dozens of relevant objects and attributes - and how to correctly configure policies - can be a lot to understand and remember over time.  As requirements change, you want to make sure the right information is being captured and analyzed.  NetVision’s SIMON managed service makes it all simple.  You don’t have to remember a thing.  Just tell us what’s important to you and we put our expertise to work to do the job quickly and efficiently.