Active Directory

Softerra Adaxes Identity and Active Directory Management Review

I’ve been asked to review many products (both hardware and software) on this blog. Many of the things I write about here are triggered by my experiences, which I think adds to the usefulness of the posts. Usually I decline, because I either don’t have an interest in the product, or don’t have the time to invest reviewing something that I can’t get a personal benefit out of the product in question.

Softerra Adaxes was one of these companies. After giving it a quick once over, my interest had been piqued. After extensive testing, I was actually happy to write a review of what the product does, and how I can see it helping people in businesses… so here is my take on the product. This is a sponsored post, but written by myself with my honest view on the product after extensive testing.

What is Softerra Adaxes?

First and foremost, this is an Active Directory (AD) Identity Management piece of software. It will talk to your AD environment (don’t worry, no schema changes required!) and give you a framework to allow automation. I’d previously looked at System Center Orchestrator (SCOrch) to look at the automation of user accounts such as creation, change, deletion – but it was too complicated for my liking. Most things required you to write your own code (PowerShell, .NET etc) and use what I’d call strange variable calls, instead of plain old nice code. To me, you have to wear a developer hat to use SCOrch for anything beyond very basic workflows.

Adaxes takes a different approach. Instead of writing your own code (which you can do still), much of it is driven in a similar way to how Outlook rules work. You can use the Adaxes Console, or Adaxes webpage to perform tasks such as ‘Create User’ – but you define the rules. For example, think of the ‘City’ field in AD. These are the rules you can set for it:

adaxes1
Those rules then end up as the only choices via a drop-down menu:
adaxes2

Having a default value if > 50% of your users are going to be in a particular city is a time saver. Same applies to being able to list several cities, and have a dropdown list to select them from – removing human error from typos. Forcing the property to being required also means it won’t be missed. To me, this gives immediate benefit in the user creation process, if the time is spent setting it up correctly.

User Creation in Adaxes

Once a user is created with your template, ‘Business Rules’ can kick in. These are more rules based on an event happening – such as a successful user creation. For me, I created business rules based on the City. If they’re in Sydney, then do all these things that applies to a Sydney person. This can be the creation of a home drive, but also can hook into Exchange or Lync to create their account in that environment too.

adaxes3

The Exchange and Lync integration allow you to have a user fully set up without even needing to worry about it. The email alias can be pulled from the username, and normal email address policies apply for creation of SMTP addresses. You can specify which DAG the mailbox will be created on too. For Lync, it’s the same story. If you’re lucky enough to have Enterprise Voice, the user’s phone number can be used as a variable to create a Line URI for the user.

Other third party systems can be manipulated by running a PowerShell script or program easily enough, or if you want to start getting tricky… there’s the Adaxes SDK for API.

When it’s all done, you can even trigger an email to alert staff that a user has been created, which could be used to alert other departments of any manual processes they need to do once a user is ‘born’.

Even better, is the easy built-in security roles. You can give HR access to create a user via the native Adaxes web page. No software required, HR follow the bouncing ball of the webpage and see a prompt for any required field, and requests can be configured to require approval before being actioned too.

What Else Can Adaxes Do?

I’ve focused on User Creation so far, because that was the first benefit I saw from Adaxes – but there’s a bunch more this software solution can do. Softerra themselves list many of the features of the product, but it’s a very open framework where you can make the software do what you need to happen.

  • Group Management

Due to the granular security model they use, you could consider end user management of groups. Email group management for end users is already possible from Microsoft Exchange, but you can’t do the same with security groups. I can see a big benefit in letting key users manage a selection of security groups which could allow things such as access to network drives and folders, access to software or permissions to an internal resource such as a SharePoint site and so on. If you’re in a Microsoft environment, everything should be security based via AD groups anyway, so this is a much nicer solution than giving those key end users an Active Directory User and Computers console.

  • Password Expiration Notifcation

There are several built in examples of ‘Scheduled Tasks’ – including some I’ve written my own script for! The ‘Password Expiration Notifier’ does exactly what I wrote here, which is to notify end users via email when they have certain days left before their password expires. My preference is to have all of these tools and triggers in a central location where all the right people can see what’s going on with ease, which is better than having Windows based scheduled tasks scattered around your servers being harder to find and manage.

password

Although I encourage everyone to know PowerShell, the reality is we all have different skills and priorities. Having middle-ware that manages the smarts, and shows you in an easily readable format reduces company risk in both managing automation as well as staff time in making changes should be at least investigated for it’s potential value. The above example out of the box had only the 7 day notification, so I copied and pasted the rules below it, and set the trigger to also happen at 1 day, matching my script. That was 10 seconds of work.

adaxes4

  • Clean Up Old Computer Records

Another example of a built in Scheduled Task is the ‘Inactive Computer Deleter’. Simply, it does a daily check for computer objects to see if they’ve been inactive for more than 12 weeks. If true, it changes the ‘When Marked Inactive’ property of the computer to the current date and time. It won’t delete the computer until it has approval, and you can tell it who to get the approval from. Tasks like this should save you time as well as helping to secure your network from rogue devices.

  • Office 365 User Management

There is also Office 365 support, which can automate tasks such as user creation, or license management. At the time of writing, an Office 365 CAL can’t be auto assigned to an Office 365 user when synced from Active Directory, but Adaxes can automate that step for you.

Conclusion

To me, the above is enough of a business case to at least consider Softerra Adaxes. Some time needs to be invested to make the software do what you want to do – every businesses’ user management processes are different. If you’re currently using just a PowerShell script, you could use that from Adaxes and build the workflow and web interface management around it for starters, then migrate tasks to Adaxes as you find time.

I can’t find many weaknesses in this solution – there’s provision for resiliency by having more than one server, the product seems secure and stable. I would like to see more built in options on what you can do out of the box (to Softerra’s credit, there is a lot of options already and is highly configurable). I noticed that I couldn’t specify some extra parameters in Lync beyond the basics of user creation, such as which policies to apply to a user. This will have to be done by calling a PowerShell script I’d write instead.

There’s also a bit of a learning curve around applying security and using the interface – not that it’s difficult, and the online documentation is extensive, but you’ll need to do a bit of tutorial reading to understand the product and how to configure it to your liking.

I also really like the potential of giving end users control over certain things. Empowering users that make decisions to act on those decisions themselves is a time saver – as is having an incredibly easy workflow approval process that doesn’t need a complicated workflow engine and a team of developers behind the scenes.

Overall, I really liked the product and the direction they have taken it. I personally recommend checking it out, and am actually in the process of implementing it in my current workplace as a result of this review, as a paid product!

 

Other Adaxes videos are available on YouTube, along with pricing available on their website (there’s also a 30 day trial – install is very simple).

Security Group Management Script

Over at eNow Consulting’s blog, I submitted an article and script on Exchange Group Management. It’s been working great for me, and hopefully will help others. I had a similar requirement around Security Groups, and this is the result.

The script itself is almost identical, but I wanted to share it anyway. I think it’s a great demonstration that you can really customise a script for whatever purpose you have. If you want to know how the script works generally, read my post at eNow, but there’s only one line different.

Instead of creating a “New Distribution Group”, it’s creating a New AD Group. The whole command is a bit different in syntax, but it’s still doing the same thing – creating a group. If you only wanted to manage existing groups, and removed the line altogether, you could manage both email and security groups from the single script (assuming a since csv file contains everything you want).

Here’s the script:

# Script to populate members of Security Groups
Start-Transcript -path C:\Scripts\Admin\Logs\securitygroups.txt
$data = import-csv C:\Scripts\Admin\securitygroups.csv
foreach ($group in $data){
New-ADGroup -name $group.GroupName -GroupCategory Security -GroupScope Universal -Path “OU=Security Groups,DC=mydomain,DC=com,DC=au” -Description “Automatically Managed by  @AdamFowler_IT’s Script”
$users = Get-ADUser -SearchBase “ou=Users,dc=mydomain,dc=com,dc=au” -Filter $group.filter
Get-ADGroup -Identity $group.groupname | Set-ADObject -clear member
Add-ADGroupMember -Identity $group.groupname -Members $users
}
Stop-Transcript

Ideally, you should intelligently create security groups based on criteria around how the business functions. For example, the Finance department can have their own security group, if their department is Finance. Makes sense right?

The catch though, is to NOT link any actual security to this group. You don’t want 30 different things (e.g. files, folders, sharepoint sites, anything you’d use a security group for) pointing to one group. What if the Finance folder needs to be accessed by the CEO of your company? You shouldn’t just add them to the group by adjusting the filter, because they’ll get access to the 29 OTHER things pointed at this group.

The way around this is to have a security group for every single separate thing you apply security to. Have a Finance drive? Then create an AD security group with a descriptive name, and then add the original Finance security group as a member. This way, if someone joins or leaves the Finance team, security will automatically apply. On top of that, if you need to give the CEO access to the Finance drive by this secondary group, knowing you’re only giving them access to that one thing.

One to one relationships on a security group and what it applies to, will make managing it in the future much easier. You could extend this even further, and have a security group for each job function – this would mean there is a CEO security group that contains the CEO, and you can then add that security group to anything they need. The biggest benefit of this is when your CEO quits and another one comes along, you can just add the new CEO to the CEO group and they’ll get the same access. Not sure what access the CEO gets? Check what the CEO security group is a member of, and all your smartly named security groups will be listed.

My last tip around security groups is to note down who’s in charge of the group in either the notes or description field. If a query comes up a year later, you may not remember who originally asked for the security. Having a person or a job title listed means you can quickly get approval for making membership changes to the group.

Thinking about how you’re going to manage things in the future and planning around it might be a bit more painful at the time, but it really pays off in the end.

Updating Active Directory from a CSV

Scenario:

You’ve been asked to populate everyone’s Active Directory job title. The payroll system is correct, and they’re able to export you a list of usernames and correct job titles. All you need to do is get that into AD.

Solution:

You could do this manually of course, but that’s no fun and a waste of time. This is one of those scenarios where you’ll hopefully think ‘PowerShell can do this!’ and possibly wonder how. That’s what I did anyway, so set out to make it work.

Here’s a fake example of the data I was working with, in a file called fake.csv:

EMPLOYEENAME,JOBTITLE
AFOWLER,IT OPERATIONS MANAGER
RSOLE,JANITOR

Tip: If you open a csv file in Excel it is a bit easier to read.

From this data, we want to match the EMPLOYEENAME to the correct AD account, then update the Job Title field from the JOBTITLE entry of the csv file.

A script that will do this is:

Import-module ActiveDirectory
$data = import-csv -path c:\fake.csv
foreach ($user in $data){
Get-ADUser -Filter “SamAccountName -eq ‘$($user.employeename)'” | Set-ADUser -Replace @{title = “$($user.JobTitle)”}
}

So, what’s happening here? It can take a bit to get your head around especially if you’re not used to programming (like me), so I’ll try to explain it:

Import-module ActiveDirectory
Importing the ActiveDirectory module so the Get-ADUser command works. If you can’t load the module, install RSAT (Remote Server Administration Tools) which includes the AD module.

$data = import-csv -path c:\fake.csv
This is setting the $data variable to memory, which will contain all the contents of the fake.csv file.

foreach ($user in $data){
This is saying ‘for each line of information from the $data variable (which is the csv file), map that to $user and do the following”

Get-ADUser -Filter “SamAccountName -eq ‘$($user.employeename)'” | Set-ADUser -Replace @{title = “$($user.Job Title)”}
This is getting any AD User where their SamAccountName matches the employeename column of the $user variable (which is the current line of information from the csv at time of processing). Then with the pipe | it will use the result to then Set the AD User’s title field (where the job title goes) to the Job Title part of our $user variable. This command will run twice, because there are two lines for ‘foreach’ to process.

}
This is closing off the command which each ‘foreach’ command runs.

 

I hope that explains it enough so you’re able to manipulate the script to your own requirements.

 

Getting AD User Data via PowerShell

It’s a common question asked of IT – “Can you give me a list of who’s in Marketing?” or “How many accounts do we actually have?”

Before PowerShell, this was a lot harder to do. There were companies like Quest Software who provided several handy tools (and still do) , or long complicated visual basic scripts.

So, how do you get a list of users? All of this is being done from the Active Directory Module for Windows PowerShell which will install as part of the Windows Server 2012 Feature – Role Administration Tools > AD DS and AD LDS Tools > Active Directory Module for Windows PowerShell.

The ‘Get-ADUser’ command is what we’ll use to demonstrate what you can do.

For starters, ‘Get-ADUser -filter*’ will get you a list of all users, and they’ll output in this format one after the other:

powershell1 (1)

A lot of information. You can specify a single user with:

Get-ADUser -identity username

which will just show you the one result.

As you may be aware, there are a lot more fields a user has than just the ones shown. You can tell PowerShell to show you all the properties by modifying the command like this:

Get-ADUser -identity username -properties *

Note that in PowerShell v4 if you get the error “get-aduser : One or more properties are invalid.” then there may be an issue with your schema. Check out this post for more information.

If there’s just one extra property you need, there’s no point getting everything, so if you needed to see a field such as “Department” for all users then adjust the command like this:

Get-ADUser -filter * -properties Department

Now, this gives the results for every single user in your Active Directory environment. You can narrow this down to a particular OU (and consequent sub OUs) by changing the command to this:

Get-ADUser -searchbase “ou=specialusers,ou=users,dc=mydomain,dc=com” -filter * -Properties Department

Now, you might be wondering how to get rid of all the standard properties and only see the ones you want.

There are two ways to pipe out the data that you want. One is with the ‘Format Table’ and the other is ‘Select Object’. Say you want a list of staff and their departments, we only need to use the ‘name’ field and the ‘department’ field.

Here’s what the two command look like, which are very similar:

Get-ADUser -searchbase “ou=specialusers,ou=users,dc=mydomain,dc=com” -filter * -Properties Department | ft name, department

Get-ADUser -searchbase “ou=specialusers,ou=users,dc=mydomain,dc=com” -filter * -Properties Department | Select-Object name, department

powershell2

The results of these commands will look exactly the same. But, when you want to export this information out, you would normally use the ‘Export-CSV’ command. If you use the ‘ft’ option, the results will not be what you expect. There is a brief writeup on this on the Windows PowerShell Blog which shows what you’ll see and explains why. The ‘Select Object’ command doesn’t have this issue.

So, if you want to output this list to a text file, here’s the command to use:

Get-ADUser -searchbase “ou=specialusers,ou=users,dc=mydomain,dc=com” -filter * -Properties Department | Select-Object name, department | export-csv c:\temp\myfile.csv

Note that you can also cheat and just pipe any output to a textfile using the old DOS redirect output method, which works even with the ‘ft’ option:

Get-ADUser -searchbase “ou=specialusers,ou=users,dc=mydomain,dc=com” -filter * -Properties Department | Select-Object name, department > c:\temp\myfile.csv

Note that one ‘>’ creates a new file or overwrites an existing, while a double ‘>>’ will create a new file or append to an existing.

Easy! Now you can provide Active Directory details to whomever asks, with a one line command that will output only the fields you want.

Full Mailbox Access to All Mailboxes in Exchange 2010

I’ll start this out by saying ‘Full Mailbox Access to All Mailboxes’ is generally a bad idea. It should be done on demand with the appropriate approvals and paper trails, but there are times when this may be needed – for example a service account for 3rd party software that has to read or add things to everyone’s mailbox in the company.

In my last post “End User Management of Distribution Groups in Exchange 2010” I explained how the new Role Based Access Control (RBAC) worked. Although this can be used to configure many things, it won’t give you full access to a mailbox as it’s an Active Directory based permission.

You can manually do this on a per mailbox level by either using the Exchange Management Console, or the Exchange Management Shell by following the Microsoft Technet documentation here and it’s fairly easy to convert this to all mailboxes in powershell, but that won’t help you with newly created mailboxes after running the command.

Yes you could run a daily task to get around that, but an alternative is giving AD access at the database level. Any existing or newly created mailbox will get permissions this way.

So, with that all in mind, the Exchange Powershell command to run on a particular database is:

Get-MailboxDatabase -identity “[mailbox database name]” | Add-ADPermission -user [username] -AccessRights GenericAll

If you don’t know what your databases are, just run ‘Get-MailboxDatabase’ or if you want to just apply the permissions to all databases:

Get-MailboxDatabase | Add-ADPermission -user [username] -AccessRights GenericAll

You can apply this to a AD group rather than a user which I’d suggest (no changes to the command required apart from typing the group name rather than user name), because it’s then easier to manage the members of the AD group than re-run this command. Also if you apply the settings to a particular user, and that user launches Outlook, all mailboxes they have full access to will auto-load into their Outlook session. Not ideal if you’ve got hundreds!

If you’d like to know more about the Add-AdPermission command, and the possible AccessRights settings check out this Technet article.