WFA 5.0 RC1 LDAP

[amayacitta]

Hi guys,

Has anyone got an example setup of LDAP for WFA 5.0? I've tried every variation I can possibly think of and keep getting the following error.

2019-12-17 00:51:00,739 ERROR [com.netapp.wfa.ldap.LdapWrapper] (default task-5) Failed to find user in LDAP: javax.naming.NamingException: [LDAP: error code 1 - 000004DC: LdapErr: DSID-0C090A4C, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v3839�]; remaining name 'DC=xx,DC=xxxx,DC=xx,DC=xx'

It's struggling with the bind from what I can tell. What format is it expecting the bind username to be in? I've tried username, domain\user, upn, direct CN path. Also when doing the test is the username supposed to be domain\user? or just user? Some added detail in the documentation would be helpful, it doesnt really go into any depth.

https://docs.netapp.com/wfa-50/index.jsp?topic=%2Fcom.netapp.doc.onc-wfa-isg%2FGUID-257AF002-75DF-4D22-8502-4CFB91FA76E3.html&cp=1_1_5_4_1

[mbeattie]

Hi,

Here is an example from my lab using WFA 5.0.1.0.0 connect to a Server 2016 DC.

The Base DN should be the distinguished name for the root of the LDAP query (not the OU path of the service account).

D:\>dsquery user -samid srv_netapp_wfa
"CN=srv_netapp_wfa,OU=Service Accounts,DC=testlab,DC=local"

Hope that helps

/Matt

[amayacitta]

Cheers Matt. I've just put 5.1.3212 on.

I now get the following erorr which suggests the base DN is wrong, but it aint. It's pefectly fine, have many sysems using the same base DN 😞 Including OCUM!

2019-12-18 13:01:13,602 ERROR [com.netapp.wfa.ldap.LdapWrapper] (default task-9) Failed to find user in LDAP: javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C09042A, comment: AcceptSecurityContext error, data 52e, v3839�]

What are you putting in the text boxes? Just the sam account name or domain\ or upn? To be fair I've tried all combinations and it doesnt work. Lost now lol

[amayacitta · Accepted solution]

OK so I got this working finally, the documentation is out of date I think for the latest version. Here was what sorted it.

1. All of the attributes were left as default, still logging on with sAMAccountName
2. The server URL only works for me when I enter ldap://servername.somedomain.co.uk or ldaps://severname.somedomain.co.uk. When doing ldap://servername.somedomain.co.uk:389 it fails to bind. Also when entering ldaps:// without :636 (SSL) at the end it prompts to accept the certificate, I presume this is becasue it's Java based and not using the windows certificate store. The back end system 100% has trust of the deployed LDAP certificate.
3. Bind username only works for me when doing DOMAIN\serviceacount. When doing just serviceaccount it fails to bind.
4. BaseDN is the same as most other LDAP systems, enter something broad where users and groups are, root of domain is OK if you're not sure. So for example dc=somedomain,dc=co,dc=uk
5. Lastly there is a bug / annoyance, each time you play with any of the fields in the list of Active Directory Servers, the password field is somehow messed up. If for example I simply change the server URL from ldap to ldaps - the bind will fail and eventually the password get's locked out. If I change the server URL AND the password at the same time it's fine. It does this with Firefox and Chrome.
6. Lastly when doing the test authenticaiton you just need the username not DOMAIN\username.

Hope this helps someone with configuring the latest version of WFA for AD.

[mbeattie]

Hi,

To elaborate a bit, consider the following OU heirarcy in Active Directory. If searching for a user in the employees OU, the Base DN must be at the root of the heriaracy to ensure the LDAP search can find users in in that OU. EG the baseDN should be "DC=testlab,DC=local" (NOT the OU path of the AD service account "OU=Service Accounts,DC=testlab,DC=local")

C:\>dsquery user -samid mbeattie
"CN=mbeattie,OU=Employees,DC=testlab,DC=local"

C:\>dsquery user -samid srv_netapp_wfa
"CN=srv_netapp_wfa,OU=Service Accounts,DC=testlab,DC=local"

Also one other point is that you must add the AD groups that are assigned to a WFA role for authentication to work.

EG ensure you have an AD group created that has the appropriate group members added

C:\>dsquery group -name WFA-Admins
"CN=WFA-Admins,OU=Groups,DC=testlab,DC=local"

C:\>dsquery group -name SGG-WFA-Admins | dsget group -members
"CN=mbeattie,OU=Employees,DC=testlab,DC=local"

Then in WFA add the group "Execution\User Management\Active Directory Groups" click Add\New type the group name, select the WFA role and click save. You must add the AD group to WFA before using the test authentication feature.

When using the "test authentication" feature i entered the username who would login to WFA via their AD account. In my case: EG "TESTLAB\mbeattie" <%NetBIOSDomain>\<%samAccountName%>

I read you note about changing the configuration and having to re-enter the password otherwise it fails and locks the account out. Sure sounds like a bug and the documentation should definately be updated, will chase it up with the developers. Thanks

/Matt

[amayacitta]

I'd appreciate it if you dont remove my posts chap. There is clearly an issue here which you just removed? It's important people can search on issues to mitigate them, that's the point in these forums.

In order to get this working I had to go against the documentation and the image which you posted.

For those that want a solution that works please do the following:

1. Enter the server URL without :389 or :636 at the end, i.e. ldaps://servername or if you want add the FQDN at the end. If you do this it will then prompt you for a certificate and will properly bind. Be aware the windows install wont use the certificates in the windows certificate store, probably because this is Java.
2. Enter the username in format DOMAIN\username not just username
3. Enter the BaseDN as you would normally do for any LDAP application, i.e. the location you want to search for which contains the users/groups your authenticating with.

There is a bug which means the password gets reset, if you play with the AD servers settings you may find the LDAP bind account being locked out. This is because any changes cause the password to be lost, when you make changes, ensure you update the password at the same time.

Hope this helps someone.