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.

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.

“Stale Accounts” in Active Directory 2008

BACKGROUND

In a recent project I had to implement a “Get Stale Accounts” script, which would be used for reporting and automatic user disabling. An account is deemed “stale” if it has not logged in for 6 months.  At a first glance, this seems like a simple task – run LDAP query, i.e. (lastLogonTimeStamp<180 days), but as you will see, is quite a bit trickier.  In this implementation I used Tools4ever UMRA and we’re currently testing this in UAT (seems to be working good).

lastLogon vs. lastLogonTimeStamp

As you may or may not know, lastLogon AD attribute has been around since the NT days and has caused developers like myself much grief. Reason is it is not replicated between the domain controllers (“DCs”). This means to truly know the last logon time, you would need to query every single DC and calculate the most recent value.

In 2003 AD lastLogonTimeStamp was introduced – same as lastLogon, except replicated. Great news right? Not so quick. By default, this attribute is replicated with a 15 day lag. Read more here. While this replication can be configured in the domain settings, it was not a luxury of my implementation, so I had to stick with lastLogon.

I should point out that both attributes are stored as count of “100s of nano seconds since 1601”.

createTimeStamp vs. whenCreated

It is possible for an account to to be stale, but also to have never logged on. In such case, lastLogon cannot be used as it would be set to 0 on all DCs. Instead, we can ask “if this account never logged on, has it existed for 180 days to be stale?” createTimeStamp AD attribute might jump to mind, but it’s no good because it’s a constructed attribute and cannot be used in an LDAP filter.

Instead, we’ll be using whenCreated. What’s interesting about this attribute is that the underlying AD value is not stored in the standard AD “100s of nano seconds since 1601” format. Instead, it’s stored in format of: “YYYYMMDDHHMMSS.0Z”. Let’s say whenCreated is 10/11/2011; the following filters would result in:

• (whenCreated>=20111010010101.0Z) – MATCH
• (whenCreated>=20111011010101.0Z) – MATCH
• (whenCreated>=20111012010101.0Z) – NO MATCH

FIRST DESIGN

Here’s the first pseudo code I came up with:

1. %TimeLimit% = today – 180 days
2. Get all accounts that existed long enough to possibly be stale
1. Query just 1 DC for (createdTimeStamp <= %TimeLimit%)
2. This is %StaleAccountsTable%
3. Loop on %StaleAccountsTable%; for every account:
1. Loop on every DC; for every DC:
1. Query DC for lastLogon (for the current user) & store newest value in the %StaleAccountsTable%
2. Perform “is stale” check in code against the freshest lastLogon
1. Remove user from table if not stale
4. Return %StaleAccountsTable%

…while this should work, I didn’t like the performance: AD would be queried (Number of DCs * Number of Accounts +1) times. If we’re talking about 5 DCs and 50,000 accounts (my project), that’s 250,000+ AD calls.

FINAL DESIGN

The following is the design I ended up implementing. Instead of 250,000 AD calls, I’m now looking at 5. Quite the improvement, eh?

1. %TimeLimit% = today – 180 days
2. Create %StaleAccountsTable% with columns: SID, lastLogon, any additional data
3. Loop on every DC
1. Query DC for all accounts that existed long enough to possibly be stale
1. LDAP Filter: (createdTimeStamp <= %TimeLimit%)
2. Table var: %StaleAccountsTable_Temp%, same columns as %StaleAccountsTable%
2. If %StaleAccountsTable% is empty – simply copy %StaleAccountsTable_Temp% into it and resume DC loop, otherwise…
3. Loop on %StaleAccountsTable_Temp%
1. Search %StaleAccountsTable% for matching SID
2. If not found – copy the row over to %StaleAccountsTable% and resume _Temp loop; otherwise…
3. Update lastLogon stamp inside %StaleAccountsTable%, only if it’s newer
4. Loop on %StaleAccountsTable% and remove any rows where lastLogon does not meet the %TimeLimit% criteria
5. Return %StaleAccountsTable%

CONCLUSION

When I set out to implement this script I thought I’d be able to whip it out in a few hours, especially having UMRA at my disposal. After much “wrestling” with AD attribute inconsistencies, I was able to finish this after almost 2 days of work. Let me know if you’re interested in the final UMRA script; I’ll see if I can throw it up here.