In previous articles I have talked at length about how Oracle Identity Cloud Service (IDCS) can use its Active Directory (AD) Bridge to synchronise users and groups into IDCS. For example, in this article I talk about syncing subsets of your AD users.
Note that IDCS fully supports Azure as well. In that scenario, the AD Bridge isn’t used and instead the industry, open-standard SCIM interface is used between Azure and IDCS. Since AD doesn’t support SCIM, the AD Bridge is used.
Syncing users from AD (or Azure AD) into IDCS is a common requirement, typically used in conjunction with federation, to enable single sign-on (SSO) into IDCS from AD through ADFS. The setup of the AD Bridge is really straightforward, as is the setup of federation between IDCS and ADFS. It is a simple two stage process to configure, as shown in the diagram below and covered within documented tutorials here and here.
Recently, a customer reached out to me with a problem. In their scenario, they have the above deployment (although Azure is the Identity Provider, not ADFS), with E-Business Suite (EBS) also integrated with IDCS to enable SSO from Azure, all the way through to EBS. Under normal circumstances, the user flow is seamless. The user doesn’t see either Azure or IDCS as they are transparently bounced between the two, before being returned to EBS as an authenticated user. However, they were having a problem with some users who were getting an error during this flow. They asked for my help to troubleshoot the problem.
I went through a number of common steps with them and quickly identified the issue. I thought it might be helpful to share my troubleshooting process, in case you are having similar problems, or just want a structured approach to troubleshooting IDCS.
Let’s start with the problem. I have replicated the problem in my environment and am using email@example.com as my test user. This user is seeing the following screen:
Now, remembering what I said before, the user shouldn’t see either an Azure/ADFS or IDCS screen. It should be seamless for them. So, we know we have an issue. Let’s examine the steps I took to identify the issue.
The first, obvious place to look is the failed login reports to see if that shows my failed user with a failed login, and any potential reason. Within the IDCS Admin Console navigate to:
Reports -> Unsuccessful Login Attempts
Hmm, nothing in there for my user: firstname.lastname@example.org.
Step 2 – Does the user exist?
Since the above report wasn’t showing my failed user, that suggests to me that IDCS doesn’t know about the user. So, the next step is to see if the user actually exists in IDCS. Still within the Admin Console navigate to Users and search for your user.
The plot thickens! The user trying to authenticate doesn’t exist in IDCS. That would explain why they can’t be authenticated, but also leads to the question, why don’t they exist? We know that our AD users are being synced with the AD Bridge so perhaps the configuration of the AD Bridge isn’t correct. Perhaps its filter doesn’t include the necessary objects for my users.
Step 3 – AD Bridge Configuration
So, my next area of investigation is the AD Bridge configuration. In my environment, my AD structure is fairly straightforward, as shown below.
The configuration of the AD Bridge is done within the IDCS Admin Console, so that is where I look next, under:
Settings -> Directory Integrations
I see my AD Bridge is configured and working fine.
We now need to look at the filter. Clicking on the entry above takes me into the configuration.
Here, I can see that I have my UK and France OUs selected and don’t have any specific filters that may exclude certain users. I am also syncing all groups underneath the Global OU. In both cases I have Include Hierarchy checked in case I have nested OUs.
Let’s recap where we are. My user, ukuser2 exists within AD in the UK OU. The AD Bridge is configured to synchronise that OU but ukuser2 isn’t being imported into IDCS.
Could there be an issue with the user’s AD record?
Step 4 – AD Bridge Logs
Since we can see that the user record we need isn’t synchronised into IDCS despite the AD Bridge having the correct scope, we need to broaden our investigations to the AD Bridge itself, since that is the component interacting with AD to retrieve the user accounts.
Connecting to the Windows server running my AD Bridge, I bring up the AD Bridge UI:
We can see that the AD Bridge is up and running
Let’s have a look at the logs and try to identify any issues. Click to take you to the folder storing the AD Bridge log files
Open up the IDBridge.log in Notepad (or your favourite editor). The log file can contain many lines, so the easiest way of looking for a problem initially is to scroll to the end of the file and perform an upwards search for Error.
Bingo, we have our problem. As the log file shows:
ERROR IDBridge - Failed to create/update User 'CN=UK User2,OU=UK,OU=Europe,OU=Global,DC=emeacp,DC=com' with error code 400.
Error message: error.identity.user.invalidPhoneValFormat : The format of the phone number (+44) 078 123 4544 you entered is invalid. Make sure that the format is compliant with national and international standards.
Upon examining ukuser2’s AD record, we can indeed see an invalid phone number.
Let’s correct that by removing the brackets.
Now, we can either wait for the next scheduled sync, or we can force an immediate sync. In my case, I’m impatient so force an immediate sync. Still within the AD Bridge configuration screen of the IDCS Admin Console, I click the button
I select Incremental Import to just bring in changes since the last sync.
And I monitor the job from the Import tab of the same AD Bridge configuration screen. After a short time, I can see that 1 user record was imported.
A quick search of Users confirms that ukuser2 is now imported into IDCS and their sign-in issue goes away. The user is now successfully able to sign into EBS.
It won’t always be the case that it is an invalid telephone number format. It could be missing, required attributes for example, e.g.
ERROR IDBridge - Failed to create/update User 'CN=UK User3,OU=UK,OU=Europe,OU=Global,DC=emeacp,DC=com' with error code 400.
Error message: error.identity.user.primaryEmailNotSpecified : The primary email must be specified.
However, in either case, the errors in the AD Bridge log file will point you in the right direction. In the case of my recent customer, the phone number was their issue, and after correcting it and a few other missing attributes on other users identified from the log, their half dozen or so missing users started syncing into IDCS.
Whilst I’m here, it would be remiss of me not to mention one other really useful tool for troubleshooting IDCS issues, the Diagnostic log.
Let’s take one more, short example. Using the same environment, I am trying to login as email@example.com, but am getting the same error screen as ukuser2 did. I have done all of the above checks and confirmed that the user exists in IDCS.
So, this time we need to understand why IDCS can’t authenticate the user when they clearly exist and therefore must be coming with a SAML assertion from ADFS. This is where Diagnostic logging comes in useful.
To use Diagnostics, you must enable it. In the IDCS Admin Console select:
Settings -> Diagnostics
As you can see from the description, if you enable any of the diagnostics, it will enable it for the next 15 mins, enabling you to reproduce the problem. It is up to you the level of diagnostics you enable. I usually enable Service View as you get the most amount of data and it’s easy to filter the resulting CSV file.
Once you have chosen your level and saved it using the button, you should now reproduce your issue. In my case, I attempted to login again with franceuser1. After completing the test, you download the diagnostic output from:
Reports -> Diagnostic Data
Ensure that you have chosen the 15 minutes time range and the Service View. That will download the CSV to your local desktop. Once you open the file, you can start looking for problems. In my scenario, it becomes apparent fairly quickly that there was a problem with the SAML assertion sent back from ADFS, spotting this in the log
Popping back to my test browser, I re-ran the test, enabling Web Developer tools to capture the SAML response from ADFS, and I see this in the response.
In this case, it appears the problem is on the ADFS side. After some investigation within ADFS, it appears that users in France within my environment are not permitted to federate to IDCS, as defined within the ADFS Access Control Policy and therefore ADFS is sending back the RequestDenied status code shown above.
I hope this has been a useful read in helping you to understand a logical set of steps to go through when troubleshooting IDCS.