Shibboleth IdP V3

Shibboleth IdP version 3.0 was released on December 22, 2014.  Detailed documentation on Shibboleth IdP v3 can be found on the Shibboleth wiki.

With the Shibboleth Consortium expected to announce the end date for the V2 Identity Provider soon, it is worth moving to Shibboleth IdP V3 for new deployments.  If you are running Shibboleth IdP V2, you may want to start planning your upgrade to V3.

System Requirements

You can find the most up-to-date list of system requirements here.  While there are no specific operating system requirements, Linux, OS X and Windows are recommended.  Oracle Java or OpenJDK versions 7 and 8 are the supported Java environments, and only Tomcat 8.x and Jetty 9.2.x are officially supported servlet containers.

What’s New in IdP V3?

Internet2’s recent press release does a good job of summarizing the key features of Shibboleth IdP V3:

  • uApprove integration, which provides individuals with information about the attributes requested by service providers and gives individuals the ability to control attribute release
  • Built-in support for CAS, which means IdP V3 can handle both on-campus SSO and federated authentication to access external SAML-protected services
  • Ability to support multiple algorithms for signing and encryption simultaneously, allowing organizations to increase the security of their transactions without compromising compatibility with older systems
  • Built-in next generation federation features such as the emerging Metadata Query Protocol, allowing on-demand metadata lookup that is replacing the need to compile ever-larger metadata aggregates
  • Support for internationalizing user interface and error messages

The Shibboleth wiki has more detail on all of the changes you can expect from IdP V3.

We are excited about Shibboleth IdP V3, and we are ready to help you plan your upgrade or new installation.  We have flexible support options to help you get past configuration issues as well as comprehensive support options for your IdP environment.

Keep an eye on our blog for more articles to help you make the transition from Shibboleth IdP V2 to V3.

Advanced Office 365 ProPlus Troubleshooting

In our previous blog post, we provided you with advice for troubleshooting Microsoft Office 365 ProPlus login and activation issues.

We wanted to share some advanced troubleshooting techniques from Microsoft Support Engineer Keith Cronsell.

If you turn on logging while troubleshooting as issue, don’t forget to turn it off after you have resolved the problem.

Troubleshooting Authentication/Sign-in/Activation Errors

The following steps will enable logging.  Once you have logging enabled, you should try to compare a “working” attempt against a “non-working” attempt to compare the results.

Set the following regkey to enable TCOTrace logs.

To do this, launch cmd as administrator and run the following command:

reg add HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Debug /v TCOTrace /t REG_DWORD /d 1 /f

Then try the activation process again from the Sign-In screen. Once the error occurs collect the following:

  1. Collect logs from %temp%
    • Office.log
    • <appname>.exe.log (where <appname> is the name of the application used for the Sign-In attempt, for example, Excel.exe.log or Winword.exe.log)
  2. Remove the regkey added.  To do this, launch cmd as administrator and run the following command:
    • reg delete HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Debug /v TCOTrace /f

Troubleshooting Office 365 Install/Update Failures

The following steps show you how to enable verbose logging to help you troubleshooting Office 365 install/update failures.

To enable verbose logging, launch cmd as administrator and run the following command:

reg add HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /t REG_DWORD /d 3

ULS log file is created both in the %temp% folder and the %windir%\temp folder.  The file name is of the following format:


For example Keith-201420141610-1434.log.  Once these logs have been retrieved and analyzed, verbose logging should be disabled by running the following command from an administrative command-prompt:

reg delete HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /f

The log output is in ULS format.  Opening the log file in Excel will help you with filtering the data.  First, you want to look for is the term “unexpected”.  You can look for “Fail” and /or “Error”

When Attempting to Install Office 365 Directly from the Office Portal

Most end user issues with installing/activating Microsoft Office 365 from the Office Portal are proxy/firewall related.  Follow the steps above to review log files.

Fiddler and Process Monitor are also great tools to use for troubleshooting Office 365 ProPlus installation and activation errors.

If possible, try to test using a less restricted proxy/firewall.  If the activation is successful on another network, you may need make adjustments to your proxy/firewall settings.

The following article can help you with determining the IP address and URL exceptions you might need to add:

Start by white listing or adding exceptions for the IP addresses and URLs under “Office 365 ProPlus”.  If you continue to have problems, add the URLs under the “Office 365 portal and identity” section.

If still have problems, try the following:

Open the command prompt (run as administrator), and use the following command to import the manual proxy settings from IE:

netsh winhttp import proxy source=ie

Now rerun the install/update

To reset winhttp back, run the following command:

netsh winhttp reset proxy

Most failed installs directly from the Office portal that are proxy related, usually fail pretty quick and usually with an error like this:

“Sorry, we ran into a problem Go online for additional help. Error Code: 30174-4.”

Or When attempting to update a client that is looking to the Office portal for updates will get something like this:

“Something went Wrong: We’re sorry, we ran into a problem while downloading updates for Office. Please check your network connection and try again later. Error Code: 30088-28 or 30088-27”

Additional Help

IDM Integration has experience with all aspects of helping organizations roll out Office 365 including SSO integration with ADFS and Shibboleth, developing rollout and migration plans, and troubleshooting Office 365 issues.  Contact us if you’d like help with your Office 365 implementation.

Microsoft Office 365 ProPlus Troubleshooting Guide

When Microsoft released Office 365 ProPlus to students as part of their Student Advantage program, it seemed like Microsoft forgot to provide IT support staff with a troubleshooting guide.

With Office 365 ProPlus becoming available as a free download for faculty and staff, it’s even more critical for IT support staff to understand how to troubleshoot end user authentication and activation issues.

We wanted to share some tips to help you with troubleshooting Office 365 ProPlus and to help you achieve a successful Office 365 ProPlus rollout.

Supported Platforms

Make sure your end users understand which platforms are supported by Office 365 ProPlus.  This will help you cut down on calls from folks trying to install Office ProPlus on unsupported platforms like Windows Vista.

Office Online might be an option for unsupported operating systems, but make sure to use an Office 365 supported browser.

Troubleshooting Tips

  • The first troubleshooting step, especially for mobile devices like tablets or laptops, is to check the system clock.  If your organization uses ADFS for authentication, and the device’s system time is not syncing with NTP, chances are good you will see an activation error.
  • Use Microsoft’s Remote Connectivity Analyzer tool to help narrow down issues that might be related to a specific ISP.  Connectivity issues can also be a factor in authentication and activation issues.
  • Microsoft has published a good support resource for troubleshooting Office 365 ProPlus error messages.  This resource can be provided to end users as a self-help guide.
  • Use Microsoft’s “Fix It” tool to completely remove Office 365.  This tool is especially important for Macs, where users often try to remove Office by deleting files from the Applications folder.
  • Being able to see the error from the end user’s perspective is essential for troubleshooting Office ProPlus issues.  We  recommend using a remote desktop access software solution, which can help you perform advanced troubleshooting procedures.
  • Not everyone can afford it, but Microsoft Premier Support is highly recommended to get the best possible support from Microsoft.
  • If you can’t afford Microsoft Premier Support, you can still engage with Microsoft experts on the public Yammer network for Office 365.  If you are in higher-ed, the UC Davis Office 365 email list is an excellent resource.

Additional Help

IDM Integration has experience with all aspects of helping organizations roll out Office 365 including SSO integration with ADFS and Shibboleth, developing rollout and migration plans, and troubleshooting Office 365 issues.  Contact us if you’d like help with your Office 365 implementation.

Configuring Microsoft IIS with multiple Shibbolized websites, using lazy sessions

We recently solved a Shibboleth problem for a customer who had Microsoft IIS, with multiple Shibbolized web sites using lazy sessions, and we wanted to share the solution.


The system worked correctly when Shibboleth was activated by browsing to the protected path in the RequestMap.  The application needed to support multiple login methods, so the lazy session initiation was used when Shibboleth requested at the beginning of the user session (see

This session initiator for the SP that was configured as the override would form the SAML request as if it was the default application.

The original configuration in the RequestMapper:

 <Host name="">
 <Path name="Default/sso" authType="shibboleth"
 requireSession="true" applicationId="access"/>

The updated configuration in the RequestMapper:

<Host name=""
 <Path name="Default/sso" authType="shibboleth"
 requireSession="true" applicationId="access"/>

We found through the Native.log file that the ISAPI module was not using the correct applicationID for the requests outside the path in the Path statement.  Adding the applicaitonID at the host level with no other requirements for a Shib session let the application override work.  This allowed the site to work without forcing Shibboleth auth, but allowed the ISAPI module to relate the Session call to the correct application ID.

We suspect that the combination of Microsoft IIS with multiple Shibbolized websites, using lazy session initiation is rare, but since we couldn’t find any documentation on this specific setup, we thought we’d share our solution.

IDM Integration Joins InCommon Affiliate Program

IDM Integration has joined Internet2’s InCommon Affiliate Program. IDM Integration (IDMI) helps customers build identity management solutions. From helping a commercial service provider overcome a single Shibboleth or SAML issue to helping an organization develop a comprehensive SSO environment, IDMI specializes in open source software integration and support. The company provides support for a wide variety of SSO layering technologies and custom integrations with ERPs, portals, learning management systems and other software systems.

“We are pleased to have IDM Integration join our Affiliate Program,” said Klara Jelinkova, senior associate vice president and chief information technology officer at the University of Chicago and chair of the InCommon Steering Committee. “We value their experience in higher education and with some of the key technology used by InCommon participants.”

The InCommon Affiliate Program provides the research and education community with a way to safely and efficiently connect with partners that can help build the necessary underlying infrastructure that supports federated identity and access management.

“We started IdM Integration because we saw a need for commercial Shibboleth support,” says Dave Alexander, one of the partners in IDMI. “We’ve been working behind the scenes with service providers to help them federate with InCommon, so we’re excited to finally join InCommon as an affiliate. We specialize in providing support and professional services for Shibboleth, and we are looking forward to helping higher ed and K-12 institutions realize the value of implementing federated authentication.”

As a way of celebrating joining the Affiliate Program, IDMI is offering InCommon participants a $100 discount on its most popular service, the Shibboleth Health Check. The service ($400 with the discount) includes two hours of phone consultation followed by two hours of research and follow-up to help resolve issues in the Shibboleth and single sign-on environment. The offer is good through October 31, 2014. Email for more information.

About IDM Integration
Since 2007, IDM Integration has been solving identity management problems. Whether we are helping customers overcome a single technical issue, or are developing comprehensive identity management solutions that integrate with existing systems, we thrive in problem solving. In addition to problem solving, we also provide support and training to ensure continued success for our clients. We support a wide variety of organizations, including corporate, nonprofit and academic, with a strong focus on commercial service providers. For additional information, please visit

About InCommon
InCommon®, operated by Internet2®, serves the US education and research communities, supporting a common framework of trust services, including the US identity management trust federation for research and education, a community-driven Certificate Service, an Assurance Program providing higher levels of trust, and a multifactor authentication program. InCommon has more than 600 participants, including higher education institutions and research organizations, and their sponsored partners, making federated identity available to more than 7.8 million individuals. For more information, see and

Shibboleth Monitoring

When you deploy a production Shibboleth IdP or SP, it is important to plan out a monitoring approach.

The Shibboleth project web site has good information on how to enable IdP and SP status monitoring.

If you are deploying a clustered IdP or SP, you should make sure you are checking the status of each node in the cluster as well as the overall health of the environment.  When you enable IdP and SP status monitoring, make sure you lock down which machines or networks are allowed to connect to your IdP or SP.

Here are some other things to consider as part of your monitoring approach for Shibboleth:

  • CPU, memory and disk space
  • Log files
  • NTP
  • Shibboleth related processes (eg. Apache, Tomcat, shibd)
  • Metadata refresh
  • Certificate expiration
  • Monitoring for your authentication or web-based SSO system
  • Monitoring for your attribute repository
  • End-to-end functional monitoring of Shibboleth authentication flow (local SP, federated SP)
  • Capturing audit logs to help with security response (eg. SIEM integration)
  • Stats monitoring – keeping track of the total number of logins and number of logins by service
  • Configuration file consistency, especially if you have a clustered IdP or SP

If you have a monitoring system like SCOM or Nagios, you can add Shibboleth process monitoring and simulate a login to a test SP or federated service.  Some federations offer Shibboleth monitoring services, and the Shibboleth community has contributed Shibboleth monitoring tools.

Contact us if you need help implementing monitoring for your production Shibboleth IdP or SP environment.