Calling UMRA thru RESTful API

I recently got to work on a web portal where we collaborated with a 3rd party vendor who implemented the front-end. I implemented the back-end in Tools4ever’s UMRA, exposed through a web service sitting on an ASP.NET MVC4 controller.

Here I present a basic example of a web service method that executes a UMRA project, setting and getting some variables along the way. You will need to have UMRA installed (the “trial” version will do, which is really a full version with a 30 day demo license), as it installs the COM object used.

C#

using System;
using System.Net;
using System.Net.Http;
using System.Web.Http;
using UMRAcomLib;

namespace com.tools4ever
{
	// ASP.NET MVC4 Controller
	public class TestController : ApiController
	{
		// POST api/Test
		public void Post()
		{
			UmraClass uc = null;
			try
			{
				// Connect to UMRA Server
				uc = new UmraClass();
				int result = uc.Connect(UMRAServer, UMRAPort);
				if (result != 0) 
					throw new Exception("Failed to connect to UMRA on "
					+ UMRAServer + ":" + UMRAPort);
						
				// Set variable in UMRA
				uc.SetVariableText("%UserName%", "Bob.Smith");
				
				// Execute UMRA Project
				result = uc.ExecuteProjectScript("UMRA Project Name");
				if (result != 0) 
					throw new Exception("Errors in UMRA project execution!");
				
				// Read variable from UMRA
				object o = null;
				uc.GetVariableText("%UserDisplayName%",out o);
				string userDisplayName = o+"";
			}
			catch( Exception ex )
			{
				// Handle error
				throw;
			}
			finally 
			{
				if ( uc != null ) uc.ReleaseConnection();
			}
		}
	}
}

Live@EDU to Office 365 Deadline: September 2013

See the original TechNet announcement.

Brief

Microsoft has been migrating Live@EDU tenants to Office 365 for sometime now and now we have a formal deadline for when Live@EDU will become history.

I advise any current Live@EDU tenants to be very pro-active about this one. While the inevitable mailbox migration will be done for you by Microsoft, any automated provisioning tools (i.e. MS’ DirSync or 3rd party like Tools4ever‘s UMRA) will be your responsibility.

Behind the Curtains

If your automated provisioning implementation didn’t go beyond basic mailbox creation, you may not care for the following. However, if you dealt with more advanced features i.e. username changes, disabled/enabled statuses, preventing password resets, SMTP proxies, etc. – read this.

There’s a fundamental difference between Live@EDU and Office 365 and understanding that difference is imperative to understanding the effort of transitioning between the two systems.

I could say Live@EDU  = MS Exchange 2010 (/w supporting Active Directory), hosted for you by MS.

However, I would say that Office 365 = a platform with its own accounting system, with plugins:

• Exchange Online (this is the MS Exchange 2010 hosted for you by MS)
• SharePoint Online
• Lync
• etc.

In case of Exchange Online, it too has it’s own accounting system.

Take Away

With Live@EDU you were dealing with only 1 accounting system. With Office 365 and Exchange Online you’ll be dealing with multiple accounting systems that sync some things between each other (but not all), but also affect 3rd party systems (i.e. SharePoint online). If you had a complex Live@EDU implementation and are still a Live@EDU tenant – you have less than a year left.

Office 365 & Live@EDU – Disable Mailbox

Takeaway

Microsoft has confirmed that the “Disable Mailbox” feature is broken (at least in Live@EDU; I’m assuming in Office 365 as well); I advise against using it, until further notice.

Disable Mailbox Functionality

If you’re familiar with Active Directory or Microsoft Exchange, you probably know of the “disabled/enabled” status that you can assign users. When it comes to Exchange Online (your tweaked Exchange 2010 hosted by Microsoft as Live@EDU or in Office 365), there’s no concept of “disabled mailbox” – no GUI options either. However, there’s this PowerShell command:

Set-CASMailbox <Identity> -OWAEnabled $false 
   -PopEnabled $false -ImapEnabled $false 
   -MAPIEnabled $false -ActiveSyncEnabled $false 
   -EwsEnabled $false

…as you can see, it’s a bunch of individual functionality switches that get turned off, to achieve the “disabled mailbox effect.”

Issue Background

I implemented an Active Directory -> Live@EDU synchronization system for a large school district in Texas; part of that system was provisioning of the AD disabled/enabled status into Live@EDU (i.e. if a kid gets suspended, they lose email, but with possibility of getting it back). I used Tools4ever‘s UMRA and here’s what my action looked like, after I plugged the PowerShell command into UMRA:

The system worked fine for a while and it wasn’t until the last months of 2012 that we started getting errors. I suspect this could have something to do with Microsoft phasing out the Live@EDU system.

Error and Microsoft Response

The most intelligible PowerShell error we got is this:

The value ‘OWA§1’ is already present in the collection

Some Googling revealed that we weren’t the only ones dealing with it, but did not give me a solution. My Client ended up contacting Microsoft Enterprise Communications Support and the response we got was:

“The error believed to be a known issue pending fix in the datacenter. […] Yes, indeed this is a known issue.”

No workaround was available at the time of this writing.

Tools4ever SSRPM Error 1329

Recently I came across an SSRPM Client in the military business who was getting Error 1329 when trying to enroll accounts over the website. SSRPM of course is the Self Service Reset Password Management – Tools4ever‘s take on the “what’s your mother’s maiden name” type of authentication.

Log On To

The investigation and resolution of this brought me to a rather cool feature of Active Directory I have never worked with before – restricting which computers a user is allowed to log on to, as a property of the actual user account:

 

Investigation

Any non-negative SSRPM error codes are simply error codes of the underlying systems (i.e. Active Directory) that are bubbled up through the error message.

A little bit of Googling on the error code reveals:

• 80090308: LdapErr: DSID-0C09030B, comment: AcceptSecurityContext error, data 531, v893
• HEX: 0×531 – not permitted to logon from this workstation
• DEC: 1329 – ERROR_INVALID_WORKSTATION (Logon failure: user not allowed to log on to this computer.)
• LDAP[userWorkstations: <multivalued list of workstation names>]
• NOTE: Returns only when presented with valid username and password/credential.

Conclusion

Long story short, some years ago they utilized this Log On To feature of AD to really lock down the system and since then have stopped, but the settings remained on many AD accounts.  As a result, certain users would be running into this error when the SSRPM server was not in the list of computers they were allowed to login to. Fix is easy: either map the SSRPM server out explicitly in the Log On To list, or don’t utilize the Log On To feature.

Office 365 & Live@EDU – Deleted Mailboxes

Tools4ever‘s UMRA has supported Live@EDU, Office 365, and Exchange 2010 Online for sometime now. I have built a number of projects integrating with all of the above, but it wasn’t until recently that I got burned with the new “Ghost Mailboxes” feature recently added in Live@EDU.

New Feature

A new feature of the Exchange 2010 Online (should be applicable to both Office 365 & Live@EDU, though I have only worked with this in context of Live@EDU) prevents “instant” mailbox deletion – instead, deleted mailboxes are placed in “deleted, but recoverable” state, which prevents the username from being used for any new accounts, but keeps it from showing up in the standard Get-Mailbox commands.

Furthermore, the “deleted, but recoverable” mailbox can have 2 possible states:

State 1: Soft Deleted

This applies to mailboxes that were never used before.  These cannot be accessed via Get-DeletedMailbox commands. We have been able to recover such mailboxes using the Undo-SoftDeletedMailbox command.

State 2: Hard Deleted

Vica versa, these are mailboxes that were previously used.  These can be accessed via the Get-DeletedMailbox and I’m assuming there are special commands for recovering mailboxes in this state.

Admin Control Panel

This is where I find Microsoft’s offering really lacking – there are no differentiation between the two states and no ability to search:

In anything other than <1000 user domain, this control panel is pretty much useless, since you’re only shown the “last 1000”.

Furthermore, I have witnessed different behavior when using PowerShell commands vs. using the control panel – i.e. I cannot delete a mailbox and then re-create a user with the same name via PowerShell, but I am able to do so via the GUI control panel.  I bet it has something to do with this (which I believe to be an isolated Live@EDU feature, so I won’t dwell any deeper for now):

Takeaways

• Deleting a mailbox can “tie up” the username and make it unusable for new accounts
• A good idea would be to rename mailboxes before deleting them (i.e. jsmith2012@…)
• Expect PowerShell work when dealing with these, as GUI control panel support is very limited

AD Password Reset vs. Change in UMRA & SSRPM

A subject of much confusion when it comes to Active Directory (“AD”) password resets are the words “change” and “reset.” First, let’s clarify some terminology. There are two ways you can “modify” a password in AD:

1) AD Password Reset

Also known as administrative password reset – this method bypasses any password history/complexity settings:

2) AD Password Change

This method requires a valid current password (underlying API calls actually require it) and this is the most common user-initiated password “modification” that upholds the password complexity and history requirements:

SSRPM

When it comes to resetting passwords using Tools4ever‘s Self Service Reset Password Management, after successfully answering the Challenge-Response questions and providing a new password, a password change takes place.

How might that be possible, if SSRPM doesn’t collect the old password? (the entire premise of SSRPM is resetting a forgotten password using “what’s your maiden name” questions) Through a simple, but clever approach: SSRPM will first perform a password reset, using a randomly generated secure string; it will then perform a password change, using the password it just set, to satisfy the API requirements.

As clever and production-proven of a method it is, it does have an occasional side effect like this one:

1. User (enrolled in SSRPM) forgets password
2. Uses SSRPM Q&A to change password
3. Q&A answered successfully, but password doesn’t meet complexity requirements – an error is shown
4. User remembers they wrote down their password
5. They now try to login with their written down password, but it no longer works
6. Why? Because of that password reset (to a random sting) that SSRPM had to do prior to attempting the password change

UMRA

Tools4ever‘s User Management Resource Administrator ships with an out-of-the-box password reset action:

There has been a case in a web portal that we built for a US state government where this action would error out with “password doesn’t meet history/complexity” error message. I’m not quite sure how this is possible, but I suspect it has to do something with running UMRA Service under a non-Domain Admins accounts (AD 2008 privileges were used).

While a password change action is not offered in UMRA out-of-the-box, it could easily be developed as a stand-alone .exe utility, or as a PowerShell action integrated into UMRA.

Office 365 – Delegated Administration /w UMRA

I’m on my second Office 365 project using Tools4ever‘s UMRA and looks like more are coming down the pipeline; Microsoft’s got a pretty hot product here!

Office 365 & Exchange 2010 Online

I’ve got my hands dirty on a recent “Live@EDU to Office 365 Migration” project; some takeaways:

• Office 365 and Exchange 2010 Online are 2 separate entities with separate account storage
• Office 365 is nothing more than accounts storage – federated identity, if you will, and “license” management (i.e. this user gets email, but this other user gets SharePoint too)
• If you create an account in Office 365 with Exchange 2010 Online license, within a few seconds that same account will exist in Exchange 2010 Online
• If you create an account in Exchange 2010 Online (using its own management tools), within a few seconds that same account will exist in Office 365 (though it will be missing a “License” and “Location” settings, marking it with errors)
• The PowerShell interface used to manage Exchange 2010 Online is the same as Live@EDU or on-premise Exchange 2010, but it’s different from Office 365 cmdlets

Office 365 Delegated Administration Web Portal

Office 365 management tools do not support the following scenario: Location-Based Access Control (LBAC) where administrators in a given business unit can only administer users within their own business unit, or other business units they have explicit administrative access to. I’ve got a project in the scoping/Proof of Concept stage where we intend to make this LBAC look something like this:

1. All Office 365 users have “Department” (or some other attribute) set to a business unit code, i.e. “FIN”
2. We set up Office 365 groups for the administrators, i.e. “Admins-FIN”
3. We set up an IIS website with Windows Authentication in Client’s on-premise Active Directory
   1. AD has single-sign-on and sync with Office 365 (using MS tools for this particular Client, but could have been using UMRA)
4. We only allow members of the “Admins-*” group to log into the website
5. All administrative actions are limited to the appropriate business units – i.e. if you’re in “Admins-FIN”, you can only find users with “FIN” in the “Department” attribute, and you can manage only their licenses, attributes, etc.

For performance sake, I’m thinking it will be best to keep the LBAC and user searching all on AD side, rather than Office 365, but either way should work.  Stay tuned for how this ultimately works out!

UMRA PSM Failover

Overview

PSM stands for Password Synchronization Manager.

Technically it’s a module of User Management Resource Administrator (UMRA), but Tools4ever markets it almost as a standalone product.

In a nutshell, what it does is “hook” into every Domain Controller in your Active Directory (rather painless GUI wizard-driven installation that requires reboot of the DCs) and then calls UMRA automation projects whenever passwords are reset in Active Directory.

We’ve implemented quite a few single sign on systems using PSM, while still allowing native AD password resets via administrator or Ctrl+Alt+Del.

Failover

In UMRA 10.9 (Build 1664 release May 18 2012) release notes I noticed the following:

4. PSM: (enhancement). The Password Synchronization Manager software plugin on the DC can now optionally automatically switch between two or more UMRA services in case of connection failures. In such a configuration, when the primary UMRA service is taken offline, synchronization notifications are automatically rerouted to an alternative UMRA service so no notifications are missed.

Here’s a screenshot of how easy this is to configure:

This is a great feature and my hat goes off to Tools4ever for including it in this release.

SSRPM Website & UMRA

When it comes to the Tools4ever suite of products I usually talk about the flagship UMRA product.  Today I’d like to focus on another popular product – SSRPM – and how we can connect it to UMRA in multiple ways.

SSRPM Overview

SSRPM stands for Self Service Reset Password Management and it’s basically a multi-faced application (Windows XP GINA hook, Vista/Windows 7 Login Screen hook, ASP website) that lets users specify challenge-response questions that can later be used to “recover” an account (read: “reset password”), or unlock an AD account:

SSRPM Native UMRA Hook

SSRPM has native UMRA connectivity out of the box:

These triggers will fire regardless of where the originating request came from – XP, Windows 7, or the web portal.

SSRPM Custom Web UMRA Hook

In a recent implementation for a US state government I made extensive customizations to the SSRPM website, which involved extensive UMRA connectivity, beyond what the out-of-box hooks shown above can accommodate.  Let’s consider a scenario where someone tries to enroll/re-enroll into SSRPM and specifies an invalid Active Directory password. We want to record all successful and failed attempts in audit log, through UMRA.

The SSRPM website is written in classic ASP, so let’s make a simple function to connect to UMRA and call an “Audit Log” project:

function UMRAAuditLog( Text )
	Set Umra = CreateObject("UmraCom.Umra")
	RetVal = Umra.Connect("localhost", 56814)
	Umra.SetVariableText "%Text%", Text
	RetVal=Umra.ExecuteProjectScript("Audit Log")
	RetVal = Umra.ReleaseConnection()
	If RetVal <> 0 Then
		response.Write("(UMRA Audit Log Error: " & RetVal & ")")
	End If
End function

…”UmraCom.Umra” DLL gets registered when you install UMRA console.

Here’s a sample usage inside SSRPM’s Logon.asp, at line 65:

If(RetValGetData <> 0) Then
	ShowGetDataToEnrollError(RetValGetData)                    
	DisplayForm = 0
	UMRAAuditLog "SSRPM Auth Failed!"
Else
	UMRAAuditLog "SSRPM Auth Succeeded!"
	Response.Redirect "CheckExistingUser.asp"
End If

Using this approach, we’ve added all kinds of new features to the default SSRPM website – including a custom “Shared Q&A” that can be used by helpdesk to verify users who call over the phone.

LBAC in Delegation & Automation

Definitions

You’ve probably heard the term “RBAC” – Role Based Access Control.  It can manifest in something like a password reset web portal – i.e. users who have “Password Reset” Role can access and use such web portal.  The role itself can be established by simply having, let’s say an Active Directory group “RBAC Pwd Reset,” though there are many other ways to establish an RBAC relationship.

Today I’d like to talk about a less used term – “LBAC” – Location Based Access Control.  Let’s say we have the same web portal that I mentioned in the RBAC description above.  If we’re a large organization, we probably don’t want an absolute “password reset” power – i.e. a helpdesk user should not be able to reset password of a domain administrator. This is where location-based segregation comes in, and boy can it get messy.

The Problem

I’ve used Tools4ever‘s UMRA to build countless automated account provisioning and web-based delegation systems. There’s a pattern I see all too frequently in how these projects unfold:

1. Implement automated account provisioning (biggest ROI)
2. Implement delegated web portal (i.e. password resets)

Here’s the problem: usually step #2 doesn’t come into the picture until step #1 is completed. Depending on how #1 was implemented, #2 will either be a graceful and simple implementation, or it will be a complex mess of a spaghetti plate – all because of LBAC.

Clean LBAC Example

Let’s say our automated account provisioning system enforced the following OU structuring:

/Users/<Building Code>/<Department Name>

…this makes it very easy to structure LBAC rules, i.e.:

• Password reset can only be performed against users in the same <Building Code> as the user performing the action
• Password reset cannot be performed against users in <Department Name> “IT”

Similar relationship could have been established using group memberships instead of OU structures and through other ways too. As a rule of thumb, whichever LBAC approach is easiest to comprehend is the best one.

Dirty LBAC Example

Let’s say your automated account provisioning is more primitive: everyone goes into /Users/Staff OU and gets a generic “Staff” group membership. Since the automated account provisioning implementation is already rolled out, you don’t get the luxury of making big changes to it, at least not for a while. So what do you end up doing to make your delegated web portal LBAC work? Well, here’s what I’ve done in the past:

• Set up SQL Table “LBAC” with columns: Location Name, Governing Users Group
• Set up according AD groups
• Find means to connect “Location Name” to your staff accounts – usually through another AD group membership
• Establish process (manual or automated) for placing staff accounts into appropriate AD groups to maintain this LBAC system

Instead of being a graceful 100% hands-off system that relies on no additional resources, besides the OU structuring that’s already there, you now get this beast.

Conclusion

Old saying goes “measure 7 times, cut once.” This couldn’t be more true when it comes to LBAC (and usually how that interacts with RBAC). If you plan your delegation at the same time as you’re planning your automation, you just might save yourself a lot of time and money down the road.