Can not join AD domain

By default, a user can add ten (10) machines to the domain.  I suspect you've hit that limit.
To delegate the ability to add more:

Delegate rights using Active Directory Users and Computers:

1.  Open the Active Directory Users and Computers snap-in.
2.  Right-click the container under which you want the computers added, and press Delegate Control.
3.  Press Next.
4.  Press Add.
5.  After adding all the users and/or groups, press Next.
6.  Select Create custom task to delegate and press Next.
7.  Select Only the following objects in the folder, check Computer objects, check the Create selected objects in this folder box, and press Next.
8.  Check the Create all child object box and press Next.
9.  Press Finish.

To change or remove the default limit:

The Active Directory attribute you need to change is mS-DS-MachineAccountQuota which is a property of the domain object. Here's the steps to change it:

- Start ADSI Edit (start/run/adsiedit.msc)
- Expand out the Domain node, right click on DC=<yourdomain>,DC=com and select properties
- Scan down to ms-DS-MachineAccountQuota
- Modify the value as appropriate, or clear the value to remove the limit entirely.

If you are using a authenticated domain user account to join these machines to domain then the limit is 10 machines / user

if you are using the domain admin account to add these machine you should not face such limitations

Also below should help.

http://support.microsoft.com/kb/243327

This is not the case, I always used Administrator account to add machines to domain. At this moment I have 27 computers (incl. servers and DC) in the domain.

Confirm please -- you are using an account that has domain administrator access to the domain, and are unable to add machines to that domain?  (I want to establish that you aren't using an account that has local administrator on the workstation/server, or a member of a different administrator's group, or even if the built-in, default administrator to the domain was renamed, and another account created within the domain with the name Administrator, but does not have administrative rights <-- not an unusual practice.)

Yes, I checked it again. I am using (domain) Administrator, member of the following groups: Administrators, Domain Admins, Enterprise Admins, Schema Admins, and some more. I can use this account to log on to the remote desktop of the DC server, no problem. I also tried other account with domain administrator rights to join the domain, same result.

Okay.  In that case the error message must be a red herring, and something else is broken.  Lets drop back 10 yards, and confirm assumptions.

1. Double check that when you are putting in the domain administrator account, that you are specifying the domain in the user line... either <domain>/<user> or <user>@<domain>.  Probably not it, but free to double check.

2. On the machine you are trying to join to the network, confirm that DNS is functional.  Do a 'nslookup <domainname>, and confirm that it returns what you believe should be responding for your domain controllers.  Do a simple nslookup for each of the possible DCs to confirm it's not giving 'strange' or unexpected results.

3. Confirm 'netdom query fsmo' gives you back good and functional servers for your FMSO roles.  I can't think of any role that could be causing THIS problem.. but it's good to confirm.  

4. If you can, confirm there isn't anything blocking standard windows ports between the workstation and server...  confirm in the domain controllers security log that it saw your authorization into the domain from that workstation.  

5. Make certain there's at least one Global Catalog available to the workstation joining the domain.

6. I assume you don't have any RODC in the environment.  Once again, I can't think of a reason it would give you THIS problem... but I haven't run down that path, 'cause they are still rare.

1. If I enter domain.com/Administrator or domain/Administrator and domain admins password, I get an error "The specified user name is invalid". If I enter the same, but with "\" instead of "/" or I omit the domain name, I get again the logon failure as described above. Just to be sure, I changed the password of the local admin to be different from domain admin´s, so if the machine tries to connect using local admin (with domain admin´s password), I should get some "wrong password error", but this never happened.

2. Nslookup replies: Server gc._msdcs.domain.com, Address (DC´s IP address). There is only one DC in the network. Ping works also.

3. Netdom runs only on DC, not on the machine to be joined to domain. It reports success, all 5 roles returned the name of DC

4. I created a separate Win 2008 server, which I try to join to domain. This and the DC run both on the same VMware host with no firewall, both have the internal firewall switched off.

5. When I run AD Users and Computers and right-click on the DC (in the domain controllers container), select Properties, in the General tab it says DC Type: Global Catalog

6. There is only this one DC.

Alright.  Still working on the assumption that the permissions aren't borked... and since you used a second account, that probably isn't it.

2. NSLOOKUP : That isn't the response I expected back.  Just to double check -- from an administrative machine still in the domain, run "dnslint /ad <ip_of_dc> /s <ip_of_dc>".  It may come back clean.  ("dnslint /d <domainname> /s <ip_of_dc>" wouldn't hurt either, just to make certain everything looks correct.

Check as well that the time on your one domain controller hasn't gotten horribly out of sync with the rest of the world.

In the event viewer for Active Directory, (now in Custom Views, Server Roles, 'Active Directory Domain Services') make certain there aren't warnings or errors relevant to this issue?  With a single domain controller, there shouldn't be replication issues.. but there could be other relevant problems.

I ran dnslint, no errors. It shows two DNS servers, one named like the DC, the other was named gc._msdcs.domain.com. There were two strange things: one was the line saying "zone expires in 1 day". Hope this does not mean anything catastrophic. Another was a line saying hostmaster: hostmaster.domain.com, but there is no hostmaster record in DNS.

System clock is Ok, error within one minute from my watch. Both machines (DC and the one to be joined) obtain the clock from the VMware host, so even if this one is out of precision, there will be no differences between the two machines

There are some odd things in the event log. The attempt to join the domain caused several records in the Security log:
- Audit success: A Kerberos authentication ticket (TGT) was requested
- Audit success: A Kerberos service ticket was requested (twice)
- Audit failure: An account failed to log on. Failure reason: The user has not been granted the requested logon... Status 0xc000015b. Event ID 4625
This sequence of records repeats twice, as if two attempts to join were made.

In the System log there is a repeating record saying "The Key Distribution Center (KDC) cannot find a suitable certificate to use for smartcard logons, or the KDC certificate cannot be verified...", Event ID 29, Source Kerberos-Key-Distribution-Center. We are not using any smart cards.

Nothing strange in the AD DS log

Thank you!  This is why I answer questions on here.  I learn so much.

I don't know yet why your global catalog entry is showing up when you request alias for the domain itself.  Not certain if it's a problem, but I've not seen that behaviour before.

If you have the time sync'd with the VMWare host, I believe the time would be consistent as long as there wasn't a timezone issue between machines.

The kerberos messages -- either you never had a Certificate Authority in your environment (which should be fine... in that case, I believe the kerberos messages are cosmetic), or you once had a CA... it's gone (or is otherwise not entirely functioning), and that's the root of your problem.  (And what I learned today was the 'certutil -dcinfo verify' command, which checks the DC cert on all the DCs at once.  Very neat.)

I feel deep respect for your investigation skills...

I really had CA installed once on the DC, then de-installed it. I hoped, Windows makes a clean de-install, which looks like is not the case. Certutil now gave me a long report about CA configuration.

Now, is there a way how to clean up the mess? Or is it better to install the CA again?

You mean, this is the cause for the Kerberos error messages only or also for the faults at joining domain?

Either in that certutil output, or within the certificate MMC snapin (I always end up opening 'MMC', Action, Add, 'Certificates', for the local machine -- then drill down in 'personal')... check the expiration date on the domain controller certificate.  I suspect that date will coincide with the date you stopped being able to add new machines.

My off-the-cuff answer will be that you'll need a CA again, but I have some things to take care of this morning.  It'll take me a bit to do some more reading...  (I'm concerned, because I don't know how the environment will handle trying to add a CA, when the existing certificates are already expired.)

When you removed the CA, did you go through a process similar to this?
http://support.microsoft.com/kb/889250

No, I simply used the Server Manager - Remove Roles. Shall I go through the described process now?

In MMC CA snap-in - Personal - Certificates, there is the certificate for DC, date of expiration 12/15/2012 (still valid).

Still likely that certificate revocation list is far out of date.
I realize you have a 2008 environment, rather than 2003.  I can't find a separate document for 2008... but that article looks to have been recently reviewed.  Go through it to the extent that it makes sense, and seems to match what you see in your environment.

Sorry, just to avoid misunderstanding: you mean I should remove the CA again according to http://support.microsoft.com/kb/889250?

Yes.  You've already effectively done step 5.f. for example... so I'm not certain how the rest of the removal will go for you.  That's why I was indicating you should go through the rest of that removal document, and do what makes sense out of there...

I went through the whole list. Steps 1-4 are not possible, because the Certification Authority tool is not there anymore. Step 5 was more or less done before, when I removed the CA role. All the other steps I did. Just at the very end I ran certutil -dcinfo deleteBad, which gave me a long list with two references to CA, but at the bottom there was "1 KDC certs for DC". KDC was mentioned before in the Audit failure message.

I tried to join the Win server to domain again, still the same error message.

Given the timing of the errors then, if it's still giving those errors when you attempt to join the domain, it looks like you'll need to put a CA back into the environment, at least to clear the errors.  If, after you can join the domain again, you decide to take the CA out of the environment again, go through the whole procedure for it's removal.

I did the whole cycle: I installed CA, restarted, tried to join the domain (error), then removed CA according to knowlegbase article, restarted, tried to join the domain again and got error again. Just those Kerberos audit failures are gone now. Still, in the event viewer, there is noted Audit failure with event id 4625, reason The user has not been granted the requested logon type at this machine

I apologize sending you down that path without success.  The only silver lining is that, by eliminating those errors, we can be pretty certain that for whatever reason the domain admin accounts have been denied some right.  Have you been locking down your domain?

Unfortunately I also don't have a test environment available to reproduce the problem, so just brainstorming other options:

  Hypothesis: The permission missing is to the default computer container.
  Test: Try to join a machine to the domain using 'netdom join' with the /ou: switch.

   Hypothesis: An explicit deny exists in a delegation of rights to add machines to the domain.
   Test: Off hand, I don't even know if an explicit deny can be set.  You should be able to look in ADUCs.  (It'll be 12 hours or so before I can look at a live system if that even exists as an option.)

There is no reason to apologize, I am happy somebody tries to solve my problems.

On netdom join I got an "access is denied error". I tried different OUs, I even created a new one, but always the same error.

In ADUC I did not find a way to restrict the right to join the domain. There is "Delegate control", which should raise the granted rights but not reduce them.

Okay.. lets try this.
In ADUC, under view, make certain 'Advanced Features' are set on.
Select an OU, and right click, and pull up it's properties.  You should have a Security tab.  Pull up advanced, and go to Effective Permissions tab.  Let it pull up the effective Permissions for one of your domain admin users.  Roll down the Effective Permissions, and see if you really have everything clicked on.  It is possible for a Deny to get set somewhere.
I _think_ what we are most concerned about is 'Create Computer objects' there... although it'll be useful to see if 'Create all child objects' is also available.

Another possibility to check while you're in ADUC: right click an OU, and see if it'll let you create a computer object directly in that interface.

I checked the Administrator´s account permissions on:
- domain object: everything is allowed, but some "delete *" permissions, all "create" permissions are set
- Computer OU: everything set (full control)

In ADUC I can create computer object in both the domain and computers container, logged in as Administrator

That eliminates permission errors in the AD itself.  Grasping straws.

  Hypothesis: The attempt to join the domain is being redirected to the wrong domain controller.  There _is_ a NS record I don't expect, but you are receiving errors on the domain controller when you try to join the machine.

Confirming assumption:  On the workstation, you are logging in as a local administrator on that workstation, and attempting to join the machine to the domain via the GUI.  (Computer/Properties or Control Panel/System)

  Another test: Create a computer object in ADUC for a machine you are attempting to join to the domain, and attempt to the join that machine to the domain.  Check all error logs to see if the error message is still that "Audit failure: An account failed to log on. Failure reason: The user has not been granted the requested logon... Status 0xc000015b. Event ID 4625" message.

In the DNS, there is only one NS record, pointing at the DC.

Confirming assumtion: exactly as you said.

I created the object, then tried to join the computer to the domain. The same error on the computer and the same error in the event log on the DC

Going back over everything.  If you do the 'new view \\[dc]' from a different machine that is in the domain, do you still get an access denied message?  (In the back of my head, I was assuming that was from a machine not yet in the domain.)

Is the domain controller using itself as it's primary DNS server?  
Are the other workstations trying to join the domain also using the same DNS server?

Do the machines that are already in the domain have any issues using the domain controller?  (Are they receiving any error messages?  Problems getting group policies, etc?)

Has the domain controller rebooted since the problem started?  (Not suggesting it should be...)

I tried now net view from a computer in the domain and from another one, not in. Both gave "System error 5, Access denied".

On the DC there is DNS and DHCP running. This is the only DC and the only DNS in network.

Machines in the network work fine, just today the AD started to remind user about passwords to be expired in two weeks, although "Maximum password age" is not set in GP. I set "Password never expires" in User properties in ADUC.

Since the problem started I restarted the DC several times, e.g. CA deinstallation required restart.

*nod*  Of course this one has been nagging at me.  I can't come up with anything that would give an access denied when trying to enumerate the system, and prevent you from joining the domain -- but not give any other errors, and allow folks already in the domain to log-in and function normally.  I'm down to really, really low probability items, like
1. Checking the arp table on a workstation after the error, and make certain it reports the MAC address of the server.
or
2. Running your favorite malware/virus scanner.

We have not found any solution, so the easiest way is to reainstall OS