Microsoft

Components of Active Directory

While working on a Windows 2008 domain it is important to understand the logical structure of Active Directory. This is what holds up your entire organization so it’s a crucial piece of any systems administrator’s duties.

So what makes up Active Directory?

Data Store

Commonly known as the Active Directory database or data store. The type of data stored in this database includes the domain information such as the topology, trust relationships, users, groups and computers. All the configuration is stored here.

Schema

Think of the schema as the blueprint that contains rules on the information that can be stored in Active Directory. Within the schema are two objects: Attribute and Class.

The schema can be extended to accommodate the needs of an organization. It is replicated to all domain controllers for consistency.

Global Catalog

The global catalog is like one large phone book. It has information about objects within the whole domain. A domain controller must be specified as a holder of the Global Catalog. Doing so makes easily searched. Such as searching for a network printer.

Replication

It’s a bad idea to just have one domain controller. Best practices is to have more than one. Replication distributes important data from Active Directory throughout the organization for high availability and performance.

{ 0 comments }

TIL: Exchange 2010 – Managing A User’s Calendar with Powershell

I can’t count how many times users will email me with a request to have access to another user’s calendar. I initially got rid of some of the requests by having everyone with “reviewer” privileges to a user’s calendar

After you get through the privacy hoops, the only way I knew to give someone access (such as editing and publishing) to another’s calendar was to give them full permission to their mailbox. Not the ideal solution, especially depending on the user you’re changing.

The other option was to give them instructions on how they can share their calendars etc.

Nowadays users request access because the other user is not available.

Today I Learned (TIL) that you can manage calendar permissions through powershell.

The command:

add-mailboxfolderpermission -identity target-user:\Calendar -user requesting-user -accessrights PublishingEditor

add-mailboxfolderpermission - this is the verb that tells Exchange what we’re doing

-target-user:\Calendar - Replace target-user with the user you are trying to edit. the “:Calendar” is the folder in which we are modifying permissions to.

-requesting-user - Replace requesting-user with the user account that needs permission

Here are the different values for the access rights:

  • None
  • Owner
  • PublishingEditor
  • Editor
  • PublishingAuthor
  • Author
  • NonEditingAuthor
  • Reviewer
  • Contributor
If you want to see what the command will do just add the -whatif parameter at the end of the command:
add-mailboxfolderpermission -identity jdoe:\Calendar -user bdole -accessrights editor -whatif
The -whatif parameter will tell you what you’re about to do. When you’re ready, just remove the -whatif parameter.
To verify the added permission you can run the command:
get-mailboxfolderpermission -identity target-user:\Calendar

{ 2 comments }

Administering Active Directory Users and Groups

I work as a Systems Administrator for a small company (user base), it is easy to manage users and groups. It used to be mostly ad-hoc with no planning whatsoever. You create a group when needed and add users to that group.

The company started doing well things started picking up. I don’t want to be in a position creating user accounts for the first half of my day. Growth began challenging the practices of administering users and groups within Active Directory.

A best practice from Microsoft is utilizing a strategy called AGDLA: Accounts are members of Global groups which are members of Domain Local groups which are added to Access control lists.

 

Accounts are the user accounts created for logins which have a unique security identifier (SID).

Global groups determine roles within the organization. I like to think of them as departments such as Accounting or Human Resources.

Domain Local groups are very similar to ACLs except that it is used to define which global groups will have access to a resource and what kind of access which is placed in an ACL of the resource.

Implementing This Strategy

My environment was full of ad-hoc groups and permissions to resources. It got so ugly and unmanageable. For example:

  • Dozens of individual users with different permissions to an Accounting folder on the file server.
  • Dozens of individual users with permissions to an email account.

What I’ve done to resolve this issue is create organizational units for each department. Within those OUs I created a global group that contained all the department users. So continuing with the Accounting department, I created a domain local group called ACL_AccountingShare_MOD and added the Accounting global group to the domain local group. If other departments collaborated within this shared folder I can add their global group to the domain local group as well.

 

Let me analyze the naming convention of the domain local group:

ACL_AccountingShare_MOD

ACL = this tells me that this group specifies who has access to a resource

AccountingShare = tells me that this group is an ACL resource group to the AccountingShare

MOD = tells me that this ACL resource group to the AccountingShare is able to modify all documents within that resource

Open the group and document as much as you can. In the Description I state what the group is for and within the Notes field I will list the path to the resource.

 

Closing Notes

Managing users, groups and resources with this method keeps everything clean. So when it comes to account creation, I create a template account that contains access to the necessary groups. It’s a disabled account within each department’s OU.

Whenever a department gets new employees all I have to do is copy the template and change the name of the account to the new user. Now I don’t have to manually set permissions to every resource that user will need.

This also eliminates the ghost accounts. A ghost account is an account that was given permissions to a resource but then that user account is deleted from Active Directory leaving just the SID within the resource’s ACL.

{ 0 comments }

← Previous Entries