- Newest
- Most votes
- Most comments
Hello! I was actually testing this on my lab last week and I got it to work. The above message points to lack of permissions on the account used to join to the Directory, not connectivity as the reason behind the issue. A couple of questions come to mind:
-
Are you using AWS Managed AD or a self managed/onprem AD with AD Connector?
-
If using AD Connector, have you performed the delegation of permissions as explained on this link? https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/self-managed-AD-best-practices.html. You might also need to supply the OU.
-
If using Managed AD, you need to specify the OU where the computer object of the storage virtual machine will be created. Since you are not the full domain admin of the Managed AD, you will need to supply the provisioned OU (i.e OU=<yourdomain>,DC=<yourdomain>,DC=<yoursuffix>) that you used to create the Managed AD (or any OU beneath it)
-
You might consider testing joining the domain using ONTAP's CLI interface:
services name-service dns create -domains example.local -name-servers 1.1.1.1,2.2.2.2,3.3.3.3
vserver cifs create -cifs-server svm1 -domain example.local -ou “OU=OUName,DC=Domain,DC=com”
I haven't tested the CLI route, but you can find more information in this link https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.dot-cm-cmpr-991%2Fvserver__active-directory__create.html&cp=2_2_29_17_0. The advantage of using the CLI is that you don't need to delete the SVM between each retry. Still, I would advise to continue using the AWS console for the time being, as that's all I used when testing in my lab.
Relevant content
- asked 3 years ago
- asked 2 years ago
- Accepted Answerasked 17 days ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
Thanks Francisco, Your point #3 made the difference and saved me a LOT of time. Thank you once again!