Bug 975182

Description of problem:
When joining the computer to AD 

Version-Release number of selected component (if applicable):
realmd-0.14.2-3.fc19.x86_64


How reproducible:
every time

Steps to Reproduce:
1. nothing (fail to create a computer account in AD before joining)
2. "realm join --user=przemek mydomain" fails with the error below
3. creating a computer account in AD 
4. "realm join --user=przemek mydomain"  succeeds

Actual results:
Failed to join domain: User specified does not have administrator privileges
! Insufficient permissions to join the domain mydomain
realm: Couldn't join realm: Insufficient permissions to join the domain 

Expected results:
an error message about not finding the computer account in the AD, or, even better, creating the computer account automatically


Additional info:

(In reply to Przemek Klosowski from comment #1)
> Actual results:
> Failed to join domain: User specified does not have administrator privileges

This message comes from samba.

> ! Insufficient permissions to join the domain mydomain
> realm: Couldn't join realm: Insufficient permissions to join the domain 
> 
> Expected results:
> an error message about not finding the computer account in the AD, or, even
> better, creating the computer account automatically

I do think that your diagnosis is incorrect. As part of the join, samba (used by realmd) tries to make a computer account. It cannot join due to missing privileges.

There's no way for it to know that if you went and fiddled directly with the domain, a later try could succeed. There could be hundreds of scenarios, where an administrator could change something in the domain (such as creating a computer account, giving you additional rights, deleting a conflicting computer account, and so on) after which a join would succeed.

Is this unfortunate? Perhaps. Active Directory does not provide us with any information as to what would be required to make the join succeed. And it would be pretty hard for Active Directory to guess this anyway since (obviously) human interaction was required in your scenario to fix the problem.

So I think this can be closed as WONTFIX, unless the samba guys have something to add, or any ideas.

I tried the join myself and then had our Windows guy try it with his AD account. It failed for both of us. He then created the AD computer account using his Windows AD admin kit. I then successfully retried the join on my Linux box, using my AD account.

This demonstrates that 1) I have the privileges to join a computer to the domain and 2) 'realm join' failure is NOT due to the lack of privilege to create a computer account. It must be some weird interaction of samba and AD.

I suspect the problem is that we only have privilege to add computer accounts to a specific container---I suspect that I have to provide the right value for -U in 'addcli preset-computer'. I will look into it and report.

I recommend against WONTFIX: if I am correct, something should be done either in Samba or realmd because such granular administrative privileges must be common in real world.

(In reply to Przemek Klosowski from comment #3)
> I suspect the problem is that we only have privilege to add computer
> accounts to a specific container---I suspect that I have to provide the
> right value for -U in 'addcli preset-computer'. I will look into it and
> report.

Please use --computer-ou command line argument:

http://www.freedesktop.org/software/realmd/docs/realm.html

If you wish to deploy realmd to default to adding accounts to a specific OU, you can do this in a realmd.conf file.

http://www.freedesktop.org/software/realmd/docs/realmd-conf.html

> I recommend against WONTFIX: if I am correct, something should be done
> either in Samba or realmd because such granular administrative privileges
> must be common in real world.

Above is the solution designed for exactly your scenario. Closing WONTFIX.

Active Directory does not provide high level diagnostic information denied the request to join a domain, and how one could theoretically take another path to joining the domain (such as a precreated account). Thus we ask for administrative privileges to complete the operation. 

In addition, in the above scenario, the error message pointed you to your administrator. This is exactly what was needed to correct the scenario.

As we saw above, it is possible to configure realmd to work around the restrictions on your domain.

If you have additional technical information about how we would detect or have Active Directory tell us such diagnostic information (and thus disproves the conclusions above), please reopen this bug.

OK, so the problem is indeed finding the correct distinguished name of the container to add the computer to. In our AD setup, we are supposed to add them deep into the tree: Site->myorg->123->123_Desktops. In Windows GUI our AD admin navigates down that tree graphically; in Linux we have to know the distinguished name, which I couldn't guess easily. It can be retrieved directly from AD LDAP 

ldapsearch -LLL -H ldap://mydomain.myorg.com -b dc=mydomain,dc=myorg,dc=com -D 'DOMAIN\myUserName'  -W '(name=123_Desktops)' dn

This DN has to be used in the realm join command as per Comment 4:

realm join --user=myUserName mydomain.myorg.com --computer-ou='...'

We could support the simpler Windows backslash style syntax in realmd. That would be Site\myorg\123\123_Desktops in your case. Would that make sense?

It would, but it doesn't address the real issue which is a combination of misleading error messages and lack of visibility into AD tree. Perhaps changing error messages to say:

Failed to join domain: User specified does not have privileges for one or more of the administrative actions (creating computer account in the appropriate container, setting one-time password, joining the computer to the domain).