RIS Build - Access is denied
in [Windows Servers]
|
Prev: Volume Shadow Copy Problems
Next: Can't load profile
From: dinny on 14 Dec 2005 09:22 Hiya, I have been using RIS successfully for some time. The RIS Server is 2003 sp1 (and so are the images that I'm deploying) Initially I set up the ris build account that I was using to deploy the ris images to be a member of the domain admins security group. I have now had some time to tidy this up and make it more secure. I have added the ris build acc to a security group - and used the "delegate control" wizard to allow this group to "join computers to the domain". This works fine on a new server (that does not already exist in the domain) - RIS creates the domain account and successfully builds the server. However if I use the same ris build acc to rebuild a server (initially built via RIS (but when the same account was a member of domain admin)) it goes through the custom osc screens, tells me that all data will be overwritten (as expected) - but then immediately fails at the end of the osc screens with the following error: Client Installation Wizard Error 00000005 Access is denied An error occurred on the server. Please notify your administrator. Press F3 to reboot I also see an error in the application event log on the risserver. Source is BINLSVC - code is 1042 Saying that there was an error generated by OS Chooser If I then remove the computer object from AD (via ADUC) it builds fine. Any subsequent rebuilds also build fine. I initially thought that it might be due to a delay in policy replication or synchronisation - but the day after - the problem is still identical. I tried stopping and starting the Remote Installation service in case that was a factor - it made no difference. This suggests to me that certain permissions/rights are applied to the computer object at the point that it is added into the domain. But I am unclear what these rights might be - or why the ris build acc which is in a group that can "create computer accounts" does not have sufficient rights to in effect re-add the account? I wondered if giving the group containing the ris build account the right to "delete computers from the domain" would make any difference. It made no difference. If I look at the security properties for the computer object (in ADUC advanced view) for two server accounts - one created by the ris build when it was a member of domain admins - and one when it was not (a member of domain admins) there does seem to be a difference: The groups and users are identical apart from on the object created when the ris build account was not a member of domain admins - the ris build account exists and has explicit permissions on the object. This account does not appear on a computer object created by the same ris build account - but when it was a member of the domain admin group. I am guessing this is causing the problem? However I do not understand why the ris build process behavoiur should act differently depending on whether the ris build account is a member of the domain admins group or not? Are there any ways of granting rights to the (non-domain admin) ris build account to allow it to rebuild machines which were initially built when it was a member of domain admins (other than re-adding the ris build account to the domain admins group)? If not - is there a way of running a script (or something) on the existing computer objects in our domain to allow them to be re-built by the non-domain admin ris build account in the future? If so - what specific rights and permissions would this script need to apply? Dinny
From: Ken Zhao [MSFT] on 15 Dec 2005 02:48 Hello Dinny, Thank you for using newsgroup! From your post, I'd like to provide you with the information for your reference. I suspect the root cause might be the delegation was failing. I suggest you clean all the delegations, and add the domain account to the domain controller security policy of add computers to the domain. More related information: =============== Allow a user or group to create a RIS managed computer account in the domain <http://technet2.microsoft.com/WindowsServer/en/Library/5baf6892-d284-4f8d-9 42a-d7f571052db91033.mspx> Planning Security for RIS Administrative Tasks <http://technet2.microsoft.com/WindowsServer/en/Library/ad768474-1f13-43a6-9 dee-262147a6cf881033.mspx> Regarding your following questions, unfortunately, I cannot find some methods or a script to do this. Are there any ways of granting rights to the (non-domain admin) ris build account to allow it to rebuild machines which were initially built when it was a member of domain admins (other than re-adding the ris build account to the domain admins group)? If not - is there a way of running a script (or something) on the existing computer objects in our domain to allow them to be re-built by the non-domain admin ris build account in the future? Hope that helps! Thanks & Regards, Ken Zhao Microsoft Online Partner Support Get Secure! - www.microsoft.com/security ===================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ===================================================== This posting is provided "AS IS" with no warranties, and confers no rights. -------------------- | Thread-Topic: RIS Build - Access is denied | thread-index: AcYAucCjXYU9dMGKTpOZhTQthXlkxA== | X-WBNR-Posting-Host: 194.60.125.248 | From: "=?Utf-8?B?ZGlubnk=?=" <dinny(a)nospam.postalias> | Subject: RIS Build - Access is denied | Date: Wed, 14 Dec 2005 06:22:02 -0800 | Lines: 90 | Message-ID: <87095BFC-FDE5-4063-9B1F-D4FE5DED4F7D(a)microsoft.com> | MIME-Version: 1.0 | Content-Type: text/plain; | charset="Utf-8" | Content-Transfer-Encoding: 7bit | X-Newsreader: Microsoft CDO for Windows 2000 | Content-Class: urn:content-classes:message | Importance: normal | Priority: normal | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 | Newsgroups: microsoft.public.windows.server.general | NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250 | Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl | Xref: TK2MSFTNGXA02.phx.gbl microsoft.public.windows.server.general:83802 | X-Tomcat-NG: microsoft.public.windows.server.general | | Hiya, | | I have been using RIS successfully for some time. | | The RIS Server is 2003 sp1 (and so are the images that I'm deploying) | | Initially I set up the ris build account that I was using to deploy the ris | images to be a member of the domain admins security group. | | I have now had some time to tidy this up and make it more secure. | | I have added the ris build acc to a security group - and used the "delegate | control" wizard to | allow this group to "join computers to the domain". | | This works fine on a new server (that does not already exist in the domain) | - RIS creates the domain account and successfully builds the server. | | However if I use the same ris build acc to rebuild a server (initially built | via RIS (but when the same account was a member of domain admin)) it goes | through the custom osc screens, tells me that all data will be overwritten | (as expected) - but then immediately fails at the end of the osc screens with | the following error: | | Client Installation Wizard Error 00000005 | | Access is denied | | An error occurred on the server. Please notify your administrator. | | Press F3 to reboot | | | I also see an error in the application event log on the risserver. | Source is BINLSVC - code is 1042 | Saying that there was an error generated by OS Chooser | | | If I then remove the computer object from AD (via ADUC) it builds fine. | | Any subsequent rebuilds also build fine. | | | I initially thought that it might be due to a delay in policy replication or | synchronisation - but the day after - the problem is still identical. | | I tried stopping and starting the Remote Installation service in case that | was a factor - it made no difference. | | This suggests to me that certain permissions/rights are applied to the | computer object at the point that it is added into the domain. | But I am unclear what these rights might be - or why the ris build acc which | is in a group that can "create computer accounts" does not have sufficient | rights to in effect re-add the account? | | I wondered if giving the group containing the ris build account the right to | "delete computers from the domain" would make any difference. | It made no difference. | | If I look at the security properties for the computer object (in ADUC | advanced view) for two server accounts - one created by the ris build when it | was a member of domain admins - and one when it was not (a member of domain | admins) there does seem to be a difference: | | The groups and users are identical apart from on the object created when the | ris build account was not a member of domain admins - the ris build account | exists and has explicit permissions on the object. | This account does not appear on a computer object created by the same ris | build account - but when it was a member of the domain admin group. | | I am guessing this is causing the problem? | | However I do not understand why the ris build process behavoiur should act | differently depending on whether the ris build account is a member of the | domain admins group or not? | | Are there any ways of granting rights to the (non-domain admin) ris build | account to allow it to rebuild machines which were initially built when it | was a member of domain admins (other than re-adding the ris build account to | the domain admins group)? | | If not - is there a way of running a script (or something) on the existing | computer objects in our domain to allow them to be re-built by the non-domain | admin ris build account in the future? | | If so - what specific rights and permissions would this script need to apply? | | Dinny | | |
From: dinny on 16 Dec 2005 06:05 Hi Ken I'm unclear how I would check or clean the delegation - the documentation I can find seems to suggest that this info is not easily accessible. The only tool I could find to view it was acldiag - which seems to suggest that the delegation is fine anyway? Similarly if the right did not exist - how can the build account create accounts that did not pre-exist (which it can) and why should it be able to recreate accounts created by itself when it was not domain admin (which it also can)? I checked the domain controller security policy - that contains "authenticated users" - but from memory there is a somewhat rarely documented hard coded limit of 10 account creations applied to this. Is that correct? Is there perhaps a similar restriction in-built on overwriting accounts created by a member of domain admins? Dinny
From: Ken Zhao [MSFT] on 19 Dec 2005 04:19 Hello Dinny, Thanks for your reply! For Acldiag syntax, you may refer to the following link: <http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Tech Ref/d2249331-6671-48bf-accc-49c8236f1543.mspx> Regarding your questions, you may refer to the following articles: Allow or prevent the installing of a RIS image by a user or group <http://technet2.microsoft.com/windowsserver/en/library/851F7E35-9A8E-451E-B C78-BC55434922661033.mspx> Securing Active Directory Administrative Groups and Accounts <http://www.microsoft.com/technet/security/topics/networksecurity/sec_ad_adm in_groups.mspx> Hope that helps! Thanks & Regards, Ken Zhao Microsoft Online Partner Support Get Secure! - www.microsoft.com/security ===================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ===================================================== This posting is provided "AS IS" with no warranties, and confers no rights. -------------------- | Thread-Topic: RIS Build - Access is denied | thread-index: AcYCMI/a/EOE0VoGSPC2gzk4WCp/JQ== | X-WBNR-Posting-Host: 194.60.125.248 | From: "=?Utf-8?B?ZGlubnk=?=" <dinny(a)nospam.postalias> | References: <87095BFC-FDE5-4063-9B1F-D4FE5DED4F7D(a)microsoft.com> <2XY9ovUAGHA.832(a)TK2MSFTNGXA02.phx.gbl> | Subject: RE: RIS Build - Access is denied | Date: Fri, 16 Dec 2005 03:05:02 -0800 | Lines: 19 | Message-ID: <74868CAA-6DB1-4F7E-8AC9-9FC2DF949195(a)microsoft.com> | MIME-Version: 1.0 | Content-Type: text/plain; | charset="Utf-8" | Content-Transfer-Encoding: 7bit | X-Newsreader: Microsoft CDO for Windows 2000 | Content-Class: urn:content-classes:message | Importance: normal | Priority: normal | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 | Newsgroups: microsoft.public.windows.server.general | NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250 | Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl | Xref: TK2MSFTNGXA02.phx.gbl microsoft.public.windows.server.general:83994 | X-Tomcat-NG: microsoft.public.windows.server.general | | Hi Ken | | I'm unclear how I would check or clean the delegation - the documentation I | can find seems to suggest that this info is not easily accessible. The only | tool I could find to view it was acldiag - which seems to suggest that the | delegation is fine anyway? | | Similarly if the right did not exist - how can the build account create | accounts that did not pre-exist (which it can) and why should it be able to | recreate accounts created by itself when it was not domain admin (which it | also can)? | | I checked the domain controller security policy - that contains | "authenticated users" - but from memory there is a somewhat rarely documented | hard coded limit of 10 account creations applied to this. Is that correct? Is | there perhaps a similar restriction in-built on overwriting accounts created | by a member of domain admins? | | Dinny |
From: dinny on 19 Dec 2005 10:01
Hi Ken, I've looked through the links you gave and nothing in them seems to explain the behavior that I am seeing. I am happy with how and why things "ought" to work. My point is that things are not working like that - even though I believe the set up to be as it should be. It still seems to me that there is some undocumented or erroneous behaviour in the situation that I am experiencing? If the build user did not have the rights to add workstations to the domain that should never work surely? Similarly if it has no rights to "re-add" a machine account - then it could never "re-add" an account - but it can. What I am trying to find out is what makes it fail purely in the situation when the computer account already exists and has been created via RIS by the same build user (but when that build user was a member of the domain admins group). I do not think that question/answer is touched upon in any of the links? I appreciate that perhaps the question may be outside of the scope of the newsgroup service - in which case just let me know. Cheers Dinny |