Problem with setting up Integrated Windows Authentication (IWA) with Portal (Tested on 10.3.1

4879
10
01-29-2017 09:40 PM
RichardsonAluvilayil2
New Contributor III

I've been trying to setup IWA on a new Portal 10.4.1. I have successfully configured IWA in the past on 10.3.1 & 10.4.1 in the same network.

However, now when I try to configure the portal identity store, it fails with the following error:

Error

java.lang.Exception: Could not connect to the user store. Please check the configuration and try again.

 

Code: 500

Portal Log:

SEVERE
Failed to update identity store. Cannot connect to user store using supplied configuration. Verify the user store configuration is correct and try again.
2017-01-29T16:29:27,947Portal AdminDEV-APPSERVER.ESRI.LOCALAdmin2050076776
WARNING
Unable to connect to the identity store using SSL. ArcGIS Server will revert to using a non-SSL connection to the identity store and credentials will be sent in clear text. In order to use SSL, verify that your identity store has SSL enabled.
2017-01-29T16:29:27,946Portal AdminDEV-APPSERVER.ESRI.LOCAL2199996776

I am not sure if the issue is with the Portal or anything is changed from my network side. Another post (Failed to return user store. For input string: "8997:266::8997:266" ) suggested to look for Windows Tunnel Adapter 6TO4 , but I could not find this on my Portal Server.

Any ideas?

0 Kudos
10 Replies
PaulDavidson1
Regular Contributor

Are you using IE?

There are issue with Chrome and 10.4.1.

There is a patch out there but I've found that while it clears up most issues, I still occasionaly have issues.

I recommend just using IE.

Info on the patch:

Portal for ArcGIS Home Application Upload Patch 

0 Kudos
RichardsonAluvilayil2
New Contributor III

Thanks Paul for your reply. I tried it on IE 11. Same results.

0 Kudos
IgorBirulya
New Contributor

Hey. have you solved the problem?

I have just hot the same one.

Ivan.

0 Kudos
deleted-user-hb3f0SCDAPf8
New Contributor II

I get the same error with 10.6 in Chrome and IE 11 :(

0 Kudos
DuarteCarreira
Occasional Contributor II

Same here... did you get over this?

0 Kudos
daveostrander
Occasional Contributor II

I encountered the same error message when attempting to configure Portal to use our enterprise active directory identity store. In my case, it was a simple syntax error in my user store configuration JSON. For the user parameter, make sure you use a double backslash (i.e. "mydomain\\winaccount"). If you use a single backslash the Portal identity store configuration will fail, and return the error above. See entire JSON example below for further context.

{   
"type": "WINDOWS",   
"properties": {     
   "userPassword": "secret",     
   "isPasswordEncrypted": "false",     
   "user": "mydomain\\winaccount",    
   "userFullnameAttribute": "cn",     
   "userEmailAttribute": "mail",     
   "caseSensitive": "false"   
   } 
}
RobertAkroyd
New Contributor II

I just came up against this issue too.

The solution for me was to use a different format for the domain\\username.

I used username@domain instead

That worked.

PatrickLadd
Occasional Contributor II

Thanks - best answer for me.  Using Windows Server 2016 and Portal 10.8.1.

0 Kudos
James_OKane
New Contributor III

I had the same issue. I found a resolution. 

I had configured my portals identity store with my own domain login for testing. Worked fine. Following ESRIs best practice advice (http://enterprise.arcgis.com/en/portal/latest/administer/windows/use-integrated-windows-authenticati...) I asked my ICT to make a basic domain account who can do lookup and whose password doesn't expire. In my case I called it GISLookUp

I kept getting the same error described even though I was sure that there was nothing wrong with the JSON. I thought that perhaps my ICT had stuffed up the account so I signed in to the domain using GISLookUp. I noticed that Windows asked me for a password change up front. Once done and signed in I was happy the account worked. Then I tried to update identity store again and it worked!

The problem for me was the new domain account hadn't been registered or activated or whatever it is that Windows does until I had done that initial sign in. Try signing in with the account you are using first.

0 Kudos