I had this exact issue and it actually turned out to be a bad password used for the user specified to join cluster to domain. Can you confirm quickly?
I want to also welcome you to the forums and above all would like to thank you for being an EMC customer.
Just to continue, we had actually started reviewing packet captures, krb5 config files, verifying all the necessary ports used in domain joins were open and everything but looking at the u/n and p/w. It is one of those you assume the client was typing in correctly. Searches in Microsoft KB articles had in a round-about way kind of suggested credentials. A quick test by logging into another workstation using the same u/n and p/w quickly confirmed a bad password. I had actually tweeted about it maybe a month ago when it happened to me since I didn't want others to overlook the same:
1) KB searches in EMC/Isilon came up short (iirc there was just one hit talking about high resource consumption on the cluster, but this was a new install)
2) It only takes a minute to quickly verify
If you've confirmed the password is fine (or even that the user has the permissions to join objects to the domain), then can you confirm that the time on the cluster is within 5 minutes of your DC? Keep in mind that best practice when joining cluster to the domain is not to manually configure an NTP server, so you may need to manually update the cluster time. After that it will synchronize time with the DC.
You can confirm (and modify) time via the following breadcrumb trail in the GUI (v6.5):
1) Cluster -> Cluster Settings -> NTP
Confirm first that you didn't manually define an NTP server
2) Cluster -> Cluster Settings -> Date and Time
Also, if time skew doesn't account for it, whether you join in the GUI or the CLI, it will make reference to a log specific to the "domain-join-results" in the following location:
I'm sure you've already reviewed them, but if you can, pasting that information may be useful. Of course clean up any information specific to your environment.
Can I also assume you have an open dialog with support to review? Support would also review this information if you were to work with them and may go as far as requesting a packet capture (don't paste here) if nothing obvious stands out for them:
Help > Diagnostics > Packet Capture
Thanks for All
My problem is reolved.
the problem is that we created a machine entry in Active directory coalled "isilon-ovt" before connecting isilon to AD server in the other side isilon by default try to create a machine in AD in the same name, so it gives an error.
we deleted de created machine and evrything is ok.
thanks again for your reactivity.
Thanks for the update.
For next time, there is a flag you can pass when you join the cluster to the domain that I'm thinking would have been related. afaik, this is only available via CLI (I could be wrong but a quick scan of the "Show Advanced Options" in the GUI don't appear to have a match):
isi auth ads join
Specifies to not delete the existing machine accounts for joining. You must specify this if you are not
allowed to create new accounts but someone else has created them for you.
Is there a document or white paper that you would suggest to understand how kerberos works with Isilon. If you could give a brief idea, that would be great