Using LDAP identity store - certificate error

ToomasAas · ‎04-29-2013

I'm setting up ArcGIS for Server 10.1 SP1 on Windows Server 2008 R2. I'm trying to use LDAP as identity store for users and roles. When I configure the identity store in ArcGIS Manager, everything seems to go successfully - I fill in all the required fields, click on 'Test connection' and the connection is successful. After completing configuration (while logged in to Manager as siteadmin) I can successfully search users and roles from the LDAP directory.

However, users configured in LDAP with Administrator-type role can not log in to Manager. The error message given by manager is simply that username or password is incorrect. When tracing the connection on LDAP server, I see the following:

TLS accept failure 1 on connection 0x8f2e5b80, setting err = -5875. Error stack:
error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown - SSL alert number 46
TLS handshake failed on connection 0x8f2e5b80, err = -5875.

The LDAP directory in question is Novell eDirectory 8.8.5. It is configured to require TLS for binds with password. The LDAP server uses SSL certificate issued by the eDirectory internal CA, not a 'well-known' commercial CA.

I have some OpenLDAP-based client systems which can successfully authenticate users to the same eDirectory. To get these working, I had to introduce our eDirectory CA certificate to the client systems. However, I cannot see a way to do something similar with ArcGIS.

Is there a way to get LDAP-based authentication working in my situation?

ToomasAas · ‎05-13-2013

Hello!

I'll attach the logs, but it seems to me that they don't contain much useful information. I changed the log level in ArcGIS Server Manager to 'Debug', but the only log lines that were generated during login attempts are:

Level Time Message Source
SEVERE 2013 5 13 19:22:20 Failed to login, invalid username or password. Admin
SEVERE 2013 5 13 19:19:40 Failed to login, invalid username or password. Admin
SEVERE 2013 5 13 19:18:35 Failed to login, invalid username or password. Admin
SEVERE 2013 5 13 19:14:36 Failed to login, invalid username or password. Admin
SEVERE 2013 5 13 19:12:26 Failed to login, invalid username or password. Admin

Logfiles in ArcGIS\Server\framework\etc\service\logs (service.log and service_error.log) end at the time when I last started the ArcGIS server, and no lines are added there during the login attempts.

Fiddler session (arcgis.saz) is also quite concise (I have never used Fiddler before, so I am not sure whether I did everything correctly).

BubbaHey · ‎05-13-2013

I see this error in the Fiddler logs: {"status":"error","messages":["Failed to login, invalid username or password."]}

Nothing really in the Server logs

ThomasMontefusco · ‎05-13-2013

There is a bug that may apply:

Bug NIM-086807
http://support.esri.com/en/bugs/nimbus/TklNMDg2ODA3

See the following Active Directory domain policy:
http://technet.microsoft.com/en-us/library/cc778124(v=WS.10).aspx

Set "Domain controller: LDAP server signing requirements" to: "None"

ToomasAas · ‎05-13-2013

There is a bug that may apply:

See the following Active Directory domain policy:
http://technet.microsoft.com/en-us/library/cc778124(v=WS.10).aspx

Set "Domain controller: LDAP server signing requirements" to: "None"

As I understand, this setting needs to be done on the domain controller in the case when LDAP authentication is done against Microsoft domain. My situation is different in that I'm trying to authenticate against Novell eDirectory.

From the Novell documentation at http://www.novell.com/documentation/edir873/edir873/data/agtxhz5.html#agwje1p:

The client needs to import a certificate that the client will trust so that the client can validate the tree CA that the LDAP server claims to be using. The client must import a certificate from the server so that whenever the server sends its certificate, the client can validate it and verify that the server is who it claims to be.

So that the client can get a secure connection, the client must be configured before the connection.

The way that the client imports the certificate differs, based on the kind of application being used. Each application must have a method to import a certificate. Netscape browser has one way, IE has another way, and ICE has a third way. These are three different LDAP clients. Each client has its method for locating the certificates that it trusts.

"The client" in this case would be the ArcGIS server, and it seems there is no way that I can import the eDirectory CA certificate into ArcGIS server so that the necessary trust would be established. The only way would be to turn of requirement for TLS on the LDAP server side, but obviously I don't want to do authentication in plaintext.

Looks like what I'm trying to do can't be done at this point, so I'll need to use ArcGIS server's internal user accounts. Fortunately there are not too many people using ArcGIS at our place right now, so this might be workable.

BubbaHey · ‎05-14-2013

Probably right. Can't help much. My last experience with Novell was in 1994. IPX/SPX, remember those days? What a pain it was to get it to work with windows. edited the autoexec.bat and all that stuff.

JustinRodriguez · ‎05-21-2013

Hello,
The logs you provided are the wrong logs. Can you upload the ArcGIS Server logs? You can find the location under Server Manager/Logs.

From the fiddler log, it looks like ArcGIS is receiving an encrypted value as the username, and it doesn't know what to do with it. I see that Tom sent the "required signing" in an earlier post, does that apply to you? Do you know why the username is being sent encrypted? I think that may be the issue. Thanks-

Justin

StephanieSnider · ‎12-23-2013

ToomasAas,
Did you ever find a solution to this issue? I've had this happen four times on three different servers (ArcGIS Server 10.2). At some point, ArcGIS Server stops recognizing the active directory and only the Primary Site admin can log in. I've had this happen on a server with GIS tier authentication, SSL enabled and using a trusted certificate. I've also had it happen on a server without SSL enabled, no trusted cert and using WEB tier authentication. The one thing that was common across the servers is that ArcGIS Server was using Windows Domain for authentication. My solution...that sometimes works, is to remove the arcgis-logsettings.json.rlock file and reset the security configuration. If that doesn't work, I restart the ArcGIS Server Service. If that doesn't work, I restart the server. That one has always worked so far. I couldn't find anything in the ArcGIS Server logs or the server manager logs that indicates what had happened to cause this. I'd be happy to hear how you solved this issue.

JustinRodriguez · ‎12-23-2013

Hello,
I hope you are doing well. It seems from the description below that your issue may be different that what was being described in the thread above. The .rlock file that you are deleting makes me think that there is some sort of communication issue with your config store. Have you been having any DNS issues or network issues? Are you using any technology that does client side caching (such as OPLOCKS)? Thank you very much-

Justin

ToomasAas,
Did you ever find a solution to this issue? I've had this happen four times on three different servers (ArcGIS Server 10.2). At some point, ArcGIS Server stops recognizing the active directory and only the Primary Site admin can log in. I've had this happen on a server with GIS tier authentication, SSL enabled and using a trusted certificate. I've also had it happen on a server without SSL enabled, no trusted cert and using WEB tier authentication. The one thing that was common across the servers is that ArcGIS Server was using Windows Domain for authentication. My solution...that sometimes works, is to remove the arcgis-logsettings.json.rlock file and reset the security configuration. If that doesn't work, I restart the ArcGIS Server Service. If that doesn't work, I restart the server. That one has always worked so far. I couldn't find anything in the ArcGIS Server logs or the server manager logs that indicates what had happened to cause this. I'd be happy to hear how you solved this issue.

StephanieSnider · ‎12-23-2013

Justin,
No, we haven't been having DNS or network issues and no we are not using any client side caching. You're right. This may be a different issue, but it seemed closer than any other post I could find.