ADFS 2.0 for Federation and Single Sign On (SSO) with Jive

Frequently I need to use ADFS to create a SSO solution for hosted Exchange scenarios.  On occasion, I need to use ADFS to federate with other systems outside of the Exchange world.  This is one of those situations.  In this example, the client needed to use AD FS 2.0 to create a SAML compliant authentication mechanism to be used with Jive Software.  The configuration turned out not to be too difficult, but I did have some issues identifying all of the components that were needed to get this working.  Hopefully this document will help.

ADFS Configuration

First and foremost, on your Windows 2008R2 server, download and install AD FS 2.0 and then install update rollup 1.

These can be downloaded here:
ADFS 2.0
ADFS 2.0 Update Rollup 1

After installing ADFS 2.0 and UR1, you can run through the configuration Wizard to get ADFS setup to validate credentials against Active Directory.

To configure it to work with Jive, begin by setting up a Relying Party (RP) Trust.  In my experience I found it was easiest to configure using the Jive metadata.  This should be https://yourcompanysHostedJiveUrl/saml/metadata.  Be sure to use HTTPS for communication between Jive and ADFS.  ADFS will ignore non-SSL communications.

When adding the RP trust, you can specify which claims (user properties) you send back to Jive.  These will vary based upon your implementation, but they can contain anything you can query through LDAP.

The most important item to configure when setting up SAML/SSO with Jive is the Name ID.  You need to configure ADFS to transform the username into a Name ID element that is sent to Jive.  Your rule should look like this:

Customize AD FS Username transformation to work with Jive SAML Name ID

Without the Name ID, Jive will not accept the SAML SSO request and the error messages are not always the most friendly.

After setting up your outgoing claims and ensuring that you are transforming the username into a Name ID, I recommend you configure two additional items on your ADFS installation to assist in troubleshooting.

First, I disable encrypoting the claims sent to Jive so that I can see them on the debug screen if there is an issue using SSO.  This can be completed by issuing the PowerShell cmdlet Set-ADFSRelyingPartyTrust -EncryptClaims $False.  (You will want to turn this feature back on when troubleshooting is done)

Second, I recommend setting the NotBeforeSkew property in ADFS as well.
Set-ADFSRelyingPartyTrust -NotBeforeSkew 5
Jive does in fact have an option to allow the server to be out of time sync, but regardless of the value I set it did not work.  We were unable to authenticate over a 300th of second variance.  When I set the skew in ADFS, the issues went away.

Jive Configuration

Inside of the Jive Admin Console, go to People, Management, then choose Single Sign On, the last choice on the Management menu.  Here you can configure Jive to use ADFS.

Your ADFS metadata URL will be https://MyADFSURL/federationmetadata/2007-06/federationmetadata.xml

It is important to note when configuring the User Attribute Mapping that I have had issues trying to map the friendly name into Jive.  What has worked without flaw is simply entering the schema name that ADFS passes.  Be sure to enable debugging on the advanced tab so that you can see the error message returned if SSO fails.

Jive Software field mapping to AD FS

There is a link on Jive’s own page that provides some helpful information.  Check out for some additional troubleshooting tips that relate to Jive and SSO in general.

Posted in ADFS | Comments closed

Cross Forest Availability (Calendaring) in Exchange 2010

We are in the process of migrating 3500 users to a recently built exchange platform as part of an acquisition.  To give executives the ability to schedule meetings between the two companies, we recently configured the availability service to provide cross-forest functionality.  The process is simple enough when you have a forest trust in place:

From the Exchange Management Shell, first run:

Get-ClientAccessServer | Add-ADPermission -Accessrights Extendedright -Extendedrights "ms-Exch-
EPI-Token-Serialization"  -User "<Remote Forest Domain>\Microsoft Exchange Servers"

Next, we execute:

Add-AvailabilityAddressSpace -Forestname -AccessMethod PerUserFB -UseServiceAccount:$true

Run the same commands in the opposite forest, give it some time to replicate between your AD servers & sites, and viola, we have cross forest availability service.

This all worked well, except we started getting the Outlook 2007 & 2010 autodiscover warning on just one side of the trust.

“Allow this website to configure server settings?”

With the proper service packs, Outlook now has a checkbox that says  “Don’t Ask Me About This Website Again”.  Unfortunately, that checkbox is USER BY USER!  Every time you schedule an appointment for a new user, that message pops up.

As part of the configuration, we had given this organization accepted email domains for both and  As such, the Exchange system is programmed to protect you from autodiscover entries that are outside of your domain.  When the availability service used autodiscover to find the CAS servers for users, it threw a security alert in forest A.

Luckily we did not need the additional address space, so we deleted the accepted domain and the issue cleared up.  If we had needed the address space, we would have needed to take an alternate route, such as a implementing a registry change for Outlook 2007 and 2010 clients.  Or we could use an Edge server to re-write the addresses on the way out of the network.

Posted in Exchange 2010, Exchange Availability Service, Exchange Calendaring | Comments closed

Mass migrations using Prepare-MoveRequest.ps1 – The Power of Powershell Part 1

I do not consider myself to be a PowerShell god, demi-god or even a Holy Half-Dead who has seen the Underverse (2 bonus points if you know where that came from!)  There are plenty of people who know PowerShell better than I do.  But, I have to admit that sometimes I get to the end of a task and I am amazed at what I was able to accomplish in PowerShell.

Today’s task looked like it could be a daunting one.  Here’s the situation:  3093 Exchange mailboxes that need to be migrated cross-forest.  FIM was used to create contact records in the destination forest, but they need to be converted to mail enabled user (MEU) objects to stage this move.  Plus, using FIM to create the MEUs is out of the picture in this case.  The contact items I have are the ones I am working with.

That means that I need to convert the users using the Prepare-MoveRequest.ps1 script.  Except there are literally over THREE THOUSAND.  And I also need to add new SMTP addresses, but we do not want a SMTP policy turned on for a few more weeks.  Having fun yet?  Last, for performance I need to scatter the moves across 3 MRSproxy servers (CAS Servers in the remote forest).

So, I turned to PowerShell to build the ultimate solution.

For starters, I needed to have a way to load the ~3100 users from a file and feed them into the prepare move script.  And I couldn’t just select contact objects, because they are not all coming.  I was given a list of users – by display name – that are being migrated.  So, I had to create a script to batch convert the 3100 contacts into mail enabled users.  It’s not elegant, but here’s what I created:


[powershell]$csvFile = Import-Csv -Path ‘C:\DisplayNames.csv’

ForEach ($row in $csvFile)
. .\Prepare-MoveRequest.ps1 -RemoteForestDomainController -RemoteForestCredential $RemoteCredentials -LocalForestDomainController -LocalForestCredential $LocalCredentials -LinkedMailUser -UseLocalObject -TargetMailUserOU FakeOU -Identity $row.DisplayName

In this script, we load each record out of the CSV and then call the move request.  A few important notes:  This is calling the second PS1 by using a DOT, SPACE, then the common .\  Second note – this script is in the same directory as the prepare-moverequest.ps1 or this method would not work.  I didn’t want a complex script so I placed this in the same directory.

I should also note that for auditing I wanted to be sure I captured ALL of the output of the Prepare-MoveRequest.ps1 script.  Anyone who has run it, knows it has a LOT of output.  I decided to use:

[sourcecode gutter="false"]Start-Transcript -path C:\output.txt -append[/sourcecode]

to ensure that I was capturing everything that was returned.  It is important to remember to issue the stop-transcript command when you are done.

In my next post I’ll outline how to batch add new SMTP email addresses that are created on the fly, without using an address policy.  Email address policies are the preferred method, for the record.  But this case required something outside of a normal process.

Posted in Exchange 2010 | Tagged , , , , | Comments closed

GR8 Microsoft Exchange Conference Presentation

First off, thank you to everyone who attended the GR8 Microsoft Exchange Conference yesterday.  I am hopeful that you were able to gather useful information from our sessions.

In this post I have attached the slides for Performance and Scalability, Virtualizing Exchange and Migrating Exchange 2003-2010.  Since we didn’t finish the session on HA&DR, I want to add some additional content to that presentation before sending it up.  I am a bit swamped today, so please check back for that post tomorrow.  Also, I will get the scripts I mentioned posted by tomorrow as well.

Happy reading and please do not hesitate to contact me with any questions!

Performance and Scalability

Migrating Exchange 2003 to 2010

Virtualizing Exchange 2010

Posted in GR8 Exchange Conference | Tagged , , | Comments closed

“Signature did not validate against the credential’s key” SSO error in Jive

The last few days have resulted in a lot of progress working on the intermittent issues that we are experiencing in our ADFS implementation providing SSO for Jive.  We have two errors that until Friday we could not track down.

One of these was the SSO error “Signature did not validate against the credential’s key”.  It turns out that the source of this issue is rather simple – the users failing to authenticate with SSO getting this error had a carriage return in their address field inside of Active Directory.  The address field in AD is a multi line field.  But most of our users had their address on one line.  But for the people that had the address <CR> suite # they were failing with the Signature did not validate against the credential’s key.  Removing the return in the address field solves the problem.

What we have not yet determined is: how are we going to resolve this.  AD has 100,000 objects so remediation could be tricky!

Posted in ADFS, Jive Software, SSO | Tagged , , | Comments closed

Authentication statement is too old to be used – Jive with ADFS for SAML SSO

We have been battling random error messages with the SSO subsystem in Jive and this one became more and more frequent – “Authentication statement is too old to be used”.  Our system is using AD FS 2.0 in a farm providing SAML 2.0 authentication support for Jive software.

Initially support told us that the problem was related to the lifetime of the RP specific entry.  Based on that advice we adjusted the authentication lifetime on our Jive relying party configuration.  But it did not resolve the issues.

After a few weeks of suffering we discovered that the issue is not related to the RP specific TTL.  The “Authentication Statement” is actually related to the master setting on ADFS.  This error references how long it has been since the IdP (AD FS 2.0 in my case) first authenticated the user.  Jive sets this to 2 hours.  ADFS defaults to 8 hours.  As soon as we updated the length of time that Jive will accept as the IdP max timeout the issue went away!

Posted in ADFS, Jive Software, SSO | Tagged , , | Comments closed