chucktryon
Dabbler
- Joined
- Sep 20, 2011
- Messages
- 26
I'm having a problem when trying to start AD. For some reason, this is particularly true when I upgrade.
I am currently testing the 8.3.1 RC1 release, though I have had this issue for several releases (at least 8.3.0).
The PROBLEM is that, when you turn on AD, the underlying scripts try to leave the domain, and then re-join the domain. This has the effect of deleting the Machine Account on the Domain Controller, and then trying to re add it.
In most situations, this isn't a big deal, as long as you have an appropriate Administrator account in the AD settings dialogue. HOWEVER, in our case, we are one office in a large, multinational organization. The administrators in our office (myself included) do not have full "Domain Administrator" access to the domain. For security reasons, we are given access to our particular OU. If we just try to add a machine to our international domain, AD will attempt to create the machine account in the "default" location, and FAIL. The way we get around this is to "pre-stage" the machine account, manually creating it inside of our OU. When the machine tries to add itself to the domain, the DC finds the existing machine account, and just updates that record... and everyone is happy!
Unfortunately, the underlying scripts in FreeNAS try to leave the domain, and then re-join. This deletes the existing machine account and then re-adds it. In our case, this fails due to insufficient permissions.
To me, the solution appears to not try to leave the domain when you are just trying to turn AD on, especially if the winbind process is already running, but rather just try to join. Only in the case where the machine can't join the domain (ie., there is something wrong with the machine account, or there is some other config issue) should it try to clean out the old account.
Alternatively, we could suggest some AD setting to our international Domain Administrators to change the "default" OU where machine accounts are created for each office. I'm no AD guru, but I think they would be open if presented with a consistent way to do this.
I am currently testing the 8.3.1 RC1 release, though I have had this issue for several releases (at least 8.3.0).
The PROBLEM is that, when you turn on AD, the underlying scripts try to leave the domain, and then re-join the domain. This has the effect of deleting the Machine Account on the Domain Controller, and then trying to re add it.
In most situations, this isn't a big deal, as long as you have an appropriate Administrator account in the AD settings dialogue. HOWEVER, in our case, we are one office in a large, multinational organization. The administrators in our office (myself included) do not have full "Domain Administrator" access to the domain. For security reasons, we are given access to our particular OU. If we just try to add a machine to our international domain, AD will attempt to create the machine account in the "default" location, and FAIL. The way we get around this is to "pre-stage" the machine account, manually creating it inside of our OU. When the machine tries to add itself to the domain, the DC finds the existing machine account, and just updates that record... and everyone is happy!
Unfortunately, the underlying scripts in FreeNAS try to leave the domain, and then re-join. This deletes the existing machine account and then re-adds it. In our case, this fails due to insufficient permissions.
To me, the solution appears to not try to leave the domain when you are just trying to turn AD on, especially if the winbind process is already running, but rather just try to join. Only in the case where the machine can't join the domain (ie., there is something wrong with the machine account, or there is some other config issue) should it try to clean out the old account.
Alternatively, we could suggest some AD setting to our international Domain Administrators to change the "default" OU where machine accounts are created for each office. I'm no AD guru, but I think they would be open if presented with a consistent way to do this.
