NetVision

NetVision Company Blog

A Discussion on Effective Audit of User Access

Dormant Accounts

Tags: , , ,

I spend so much time thinking about the bleeding edge of access reporting that I often forget to mention the basics. In the next few posts, I’ll write about a few of those basic reporting needs  starting today with Dormant Accounts on both Microsoft Active Directory and Novell eDirectory.

These are accounts that have been dormant or unused for some period of time. The most obvious indicator of a user account being dormant is that it has not been used to authenticate in a while. You can easily see this by looking at the user object’s attributes. Obviously, a monitoring-only approach would not be able to tell you what’s NOT happening. So, to effectively report on inactivity, you need a solution that would query your network directory on your schedule. NetVision’s NVAssess does exactly that. And rather than ONLY offering a list of dormant accounts based on your criteria (30 days ? 90 days?), we have built-in ability to provide a nice chart that quickly identifies the dormant user accounts that are still enabled and therefore represent a greater security risk. And we can take that a step further.

Many of our manufacturing customers, as an example, have a significant subset of users that do not regularly authenticate. These employees don’t use computers for their day-to-day routines but occasionally need to log on to the network to access HR or other information. In these instances, we can extend our dormant account reporting to include additional logic. For example, members of a certain group or with a given attribute value can be identified separately from other employees. This makes it easy to see which dormant accounts are expected (or normal) and which may represent a higher risk profile.

NVAssess can also auto-process the dormant accounts based the your selected criteria to disable those accounts, revoke permissions, remove group memberships, and move the account to a specified OU within the directory. This makes the entire process automated and hands-off. When your executive staff or auditors run periodic reports, they’ll never find a list of still enabled dormant accounts that are in breach of your security policy.

NVAssess has been on the market for over 15 years. Dormant accounts reporting is just one drop in the bucket in terms of what it can do. Let us know if you’d like more details.

Take Ownership Issue

Tags: , , , ,

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 Share Permissions

Tags: , , , ,

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.

The Windows Owner Attribute

Tags: , , ,

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.

Active Directory UserAccountControl

Tags: , , ,

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.

Windows File System Permissions

Tags: , , ,

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.

Tracking Failed Logon attempts to Active Directory

Tags: , , ,

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.

Active Directory Last Logoff

Tags: ,

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.

© 2009 NetVision Company Blog. All Rights Reserved.

This blog is powered by Wordpress and Magatheme by Bryan Helmig.