JDA Allocation LDAP currently supports only Active Directory. Future expanded LDAP support may use a different implementation.
Q1. Detail specification of the authentication solution for each of the application. How does JDA Allocation work with the LDAP URL specified within the connection file.
A: The LDAP path specified is used to communicate with a single domain within AD.
Q2. How does JDA Allocation use LDAP and how it integrates with AD.
A: In Allocation the LDAP path is simply a domain name expressed in a different form.
Q3. What credentials does JDA Allocation use and in what form.
A: There are two parts to this answer:
(1) For Allocation administrators to query for domain users to add to Allocation:
It uses the current Windows User’s permissions, running Allocation Admin, against Active Directory. System.DirectoryServices attempts to connect using Windows Integrated Authentication.
(2) For the Allocation Client user to Authenticate against AD:
The User ID and Password specified are used in the constructor of a DirectoryEntry object. The System.DirectoryServices.AuthenticationType is Secure.
From MSDN docs:
Secure: Requests secure authentication. When this flag is set, the WinNT provider uses NTLM to authenticate the client. Active Directory uses Kerberos, and possibly NTLM, to authenticate the client. When the user name and password are a null reference (Nothing in Visual Basic), ADSI binds to the object using the security context of the calling thread, which is either the security context of the user account under which the application is running or of the client user account that the calling thread is impersonating.
Q4. Is it part of the windows API ? What API is it calling.
A: To Find Users within the domain:
DirectorySearcher.FindAll (http://msdn.microsoft.com/en-us/library/system.directoryservices.directorysearcher.findall.aspx)
Q5. What response does it send back (e.g. Known user, active user) ? where is it getting information from.
A: The DirectoryEntry object constructor will throw an exception if the specified user ID/password cannot be authenticated.
Q6. How does JDA Allocation handle suspend accounts etc.
A: Allocation does not currently support AD enabling or disabling user account control.
Q7. How are AD accounts syncronized with the backend database meta data.
A: Passwords are not synchronized. The database only contains the AD user ID.
Q8. What API is being used. How does it manage the authentication (i.e. what interaction is there between the Client and DB through the authentication processes for either an LDAP or non-LDAP user.
A: For Allocation Directory Service users there is no communication with the database, all authentication is handled by the client directly with Windows, as stated in answer 3 above. For other Allocation users the password is encrypted and authenticated using system APIs.
Q9. Please advise configuration for TLS, on the assumption that passwords are passed in plain text format.
A: Passwords are never transferred. They are used directly with the Windows API, which authenticates the user.
Q10. Which version of ‘Bind’ the LDAP is using – eg Simple Bind, SASL Plain etc.
A: AD handles this.
Q11. Is the “Connection File (CXN)” encoded or encrypted?
A: Yes, the file is encoded. However, the connection file does not contain application user (LDAP or AD) authentication information. It contains database connection information only. The application code encrypts the database connection information using DES and stores it in a proprietary binary format
Q12. What is the algorithm/cipher used to encode/encrypt the CXN file?
A. DES (Data Encryption Standard)
Q13. Where is the decryption key stored?
A. In a proprietary binary format
Q14 Does the application support connecting to LDAP/AD over SSL?
No, the Authentication type used is Secure; and Secure Socket Layer (SSL) is a different Authentication type. **Refer to the url https://msdn.microsoft.com/en-us/library/system.directoryservices.authenticationtypes(v=vs.110).aspx
Q15. Is there support for 2-factor authentication?
A. No, it does not. |
