User lookup fails with 'PartialResultException' in Fisheye Server
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
LDAP Active directory synchronization in the Fisheye/Crucible server fails. Due to this, the new users cannot log in to the application. When tried to sync by clicking "Synchronise" button from UI, it says Synchronisation failed. See server logs for details.
javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: DomainDnsZones.example.com:389 [Root exception is java.net.SocketTimeoutException: connect timed out]]Other root exceptions can be:
- javax.naming.PartialResultException
java.net.UnknownHostException
Environment
Fisheye Crucible 4.8.8
This may be applicable to other supported Fisheye Crucible versions
Diagnosis
From the logs, you'll see
YYYY-MM-DD,089 ERROR [qtp79644918-265 ] fisheye TotalityFilter-logExceptionDetails - Exception "com.atlassian.crowd.exception.runtime.OperationFailedException: org.springframework.ldap.PartialResultException: nested exception is javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: DomainDnsZones.example.net:389 [Root exception is java.net.SocketTimeoutException: connect timed out]]" (javax.servlet.ServletException) while processing "/admin/editUserGroups-modify.do" (Referer:"<FISHEYE_BASE_URL>/admin/editUserGroups.do")
javax.servlet.ServletException: com.atlassian.crowd.exception.runtime.OperationFailedException: org.springframework.ldap.PartialResultException: nested exception is javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: DomainDnsZones.example.com:389 [Root exception is java.net.SocketTimeoutException: connect timed out]]
at com.opensymphony.webwork.dispatcher.DispatcherUtils.serviceAction(DispatcherUtils.java:285) [webwork-2.2.7-atlassian-37.jar:?]
at com.opensymphony.webwork.dispatcher.ServletDispatcher.service(ServletDispatcher.java:111) [webwork-2.2.7-atlassian-37.jar:?]
Caused by: javax.naming.CommunicationException: DomainDnsZones.example.com:389 [Root exception is java.net.SocketTimeoutException: connect timed out]
at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:96) [?:1.8.0_362]
at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:151) [?:1.8.0_362]
at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreReferrals(AbstractLdapNamingEnumeration.java:325) [?:1.8.0_362]
at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreImpl(AbstractLdapNamingEnumeration.java:227) [?:1.8.0_362]
... 18 more
Caused by: java.net.SocketTimeoutException: connect timed out
at java.net.PlainSocketImpl.socketConnect(Native Method) [?:1.8.0_362]
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) [?:1.8.0_362]
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) [?:1.8.0_362]
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) [?:1.8.0_362]
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) [?:1.8.0_362]
The LDAP synchronization process gets timed out due to javax.naming.PartialResultException while updating user and group memberships.
To verify if this is the case,
- Turn off 'Follow Referrals' in the 'Advanced Settings' section of your User Directory configuration.
- Connect to the root DN of your LDAP server.
- If no errors show in the logs, then it's a DNS error.
Cause
Background:
Active Directory servers are integrated with DNS and modify entries in the DNS server. They refer to themselves in the root of their LDAP tree. If the application server is pointed to the root of the LDAP tree, and "follow referrals" is turned on, then:
- The Fisheye application will search for users.
- AD server will respond with users and the referral that's in the root of the LDAP tree because there could be more users over there.
- The Fisheye application will follow the referral. This will result in:
- A DNS lookup of the base DN (
dc=example,dc=commeans a lookup forexample.com) - A connection to port 389 or 636 at
example.com, which is back to the same server.
- A DNS lookup of the base DN (
- The application will continue and read the rest of the objects in the domain as normal.
The possible cause is that the application can't perform a DNS lookup on the referral in the AD server root. Problems like this are most commonly caused by the server that Fisheye/Crucible is running on not having the same DNS server as the Active Directory server.
Solution
- Configure the server that Fisheye/Crucible is running on to use the DNS server that the Active Directory server is integrated with.
- Double-check if the DNS server address has been changed recently. Since the DNS server record the Fisheye application information, please delete the Fisheye application address information from the DNS server to resolve the issue. (or)
- If the above steps are not possible, disable 'Follow Referrals' under the advanced settings of your user directory
What are the implications of disabling 'Follow Referrals'?
- If you only have one domain, there should be no adverse effects.
- If you have multiple domains joined in a Forest, then any cross-domain memberships will not be resolved.
- If you must have cross-domain memberships and you can't fix the DNS issues, then you can point Fisheye at your Global Catalog. This is read-only, but it does contain all users, groups, and memberships from across your Forest. Talk to your AD admin for Global Catalog connection details.