DCOM Security torture. Stuck on run time error 70 (Permission Denied)

[Charis]

I am a VB 6.0 programmer (from Australia) experimenting with DCOM.<br>&nbsp;<br>I have an experimental network set-up with one NT Server 4.0(SP4) which I'll call NT-SERVER and one NT Workstation (SP6) which I'll call NT-WS1. I am experimenting with a test DCOM application written in VB6. The problem is that no matter what I do I can only successfully activate the DCOM server in the NT Server when I log on as Administrator on the client machine. Whenever I use the&nbsp;&nbsp;account (USER1), which mind you belongs to the Administrator's group I keep getting Error 70 - Permission denied.<br>&nbsp;<br>I have read just about all KB DCOM security articles I've found with no success.<br>&nbsp;<br>I have changed DCOMCNFG tens of times and experimented with all sorts of combinations including giving permissions to everyone and having authentication level set to none. I have also changed DCOMCNFG in the client's machine. The event viewer on the client machine gives me this message on each first attempt after loggin on:<br>&nbsp;<br>User: MYDOMAIN\USER1<br>Computer: NT-WS1<br>Event ID: 10006<br>Source: DCOM<br>Type: ERROR<br>Category: None<br>&nbsp;<br>DCOM got error &quot;General access denied error &quot; from the computer NT-SERVER when attempting to activate the server:<br>{95AC572E.......}<br>&nbsp;<br>I even tried to give the USER1 account every single possible type of access permission with no avail. I log on to the MYDOMAIN domain using the USER1 account which proves the USER1 is a domain account. I turned audit on for logon/logoff events and I can see the entries for USER1 on the server's event viewer.<br>&nbsp;<br>I gave NTFS permissions to USER1 for the DCOM server exe file on the NT Server thinking this would probably generate an ACL used by the access token which would give USER1 the necessary permission to the PROGID in question. It didn't make a difference. <br>&nbsp;<br>My DCOM settings on the server for the application are:<br>&nbsp;<br>Authentication Level: Connect<br>Location: Run application on this computer<br>Security: I use the custom access permissions for all three tabs. Believe me, the list is packed with names and groups including USER1, Everyone and the lot.<br>Identity: This user&nbsp;&nbsp;&nbsp;(User MYDOMAIN\Administrator)<br><br>I am new to DCOM and would appreciate any help to point me to the right direction.<br>&nbsp;

 

[johnk]

Our solution is not very elegant, but I'm glad to share it.&nbsp;&nbsp;I am not myself very technical, so you may have to ask back for details.<br><br>We use the security functions of NT Server in a reverse sort of way.&nbsp;&nbsp;We give our users administrative priviledge which allows them to instantiate objects on the server.&nbsp;&nbsp;Then we select security options which limit their access to only the files and directories they need.<br><br>I'll bet there is a better way and I'd like to hear it, but this works for us. <p>John Kisner<br><a href=mailto:jlkisner@jlkisner.com>jlkisner@jlkisner.com</a><br><a href= > </a><br>

 

[Charis]

Thank you very much for your reply John.<br><br>I am so desperate to have this problem fixed that I appreciate any input.<br><br>You mentioned in your reply about giving USER1 administrative rights. This is what I have done by placing USER1 in the Administrators group. It dind't help. It seems to be a registry or ACL permission that stops USER1 from activating the DCOM server. As I mentioned in my question, the Administrator has no problems in activating the DCOM server application from the workstation but USER1 keeps getting the infamous run time error 70.<br><br>Being new in DCOM I can only express my opnion about giving Administrative rights to users. I think it can be fraught with danger. Most likely a better solution is to use DCOMCNFG and set default impersonation level to 'Impersonate' in the 'Default Properties' tab of DCOMCNFG. By click the properties of the application (still in DCOMCNFG) select 'This User' in the 'Identity' tab. Then as User/Password use the Administrator's account userid/password. Now, in the 'Custom Access Permissions' options add the group of users who will be accessing the application. According to what I've read it is much easier to administer access to the application using a group rather than doing on it on a user basis. <br><br>Now this is my understanding of what happens in this scenario:<br><br>A user sends a request to activate the server. The NT server will check if the group to which the user belongs to has access permissions to the DCOM server. Now who's going to lauch the server will be the Administrator and not the user because this is what we did in the 'Identity' tab of the application. DCOM will impersonate the user call and activate the server on his/her behalf. This scenario seems to be a safer approach. <br><br>Tips on good tools:<br>The other day I came accross some interesting tools for monitoring file and registry activity on NT. Although I still couldn't solve my problem and gave me better insight of NT processes. Check out FILEMON and REGMON in <A HREF="

http://www.sysinternals.com"

TARGET="_new">

http://www.sysinternals.com</A><br>

 

[Charis]

The problem has been solved, praise God!!<br><br>Here's the explanation for those who might be interested:<br><br>Activation security has two levels: machine-wide settings and per-class settings. I had configured the server class using the DCOMCNFG application settings for both ‘Custom Access Permissions’ and ‘Custom Launch Permissions’ under the Security tab. I erroneously thought that by configuring DCOM at an object level would certainly override default configurations at machine level. WRONG! See, when the Service Control Manager (SCM) receives a request from the the client machine (USER1) it will check the Access Permission settings against the machine-wide settings even though you have set it at the object level. Now it all becomes obvious to me (bear with me I am learning) that SCM at this point in time will not instantiate the server object (where class access settings live) until it can check the client’s ACL againt the machine-wide settings for DCOM. <br><br>I noticed in REGMON (great tool) while observing the client’s request for activation that this registry entry was accessed: HKLM\SOFTWARE\Microsoft\OLE\Default Access Permission. If the request fails this check, the object won’t be activated at all. <br><br>You can change the machine-wide settings for ‘Access Permissions’ by clicking the Edit button in DCOMCNFG under Default Security tab. As soon as I added USER1 to the Access Permission list my problem was solved. I must point out that I needed to re-boot the NT Server for the changes to take effect. <br><br>I hope this can be of help. My next step now is to provide inter-component communication on the Web. DCOM requests can be blocked my fire-walls but can be allowed through http requests. <br>

 

[jcasetnl]

A few suggestions. Create a local user on each box with the same username and password. Add that to your launch and access control lists. Now, whenever you make *any* permissions changes to an object, if the object has already been instantiated you must kill dllhost.exe. As long as it lives (90 min or 2 hours, can't remember) it will retain the old security settings. The long way is to reboot the machine.

Another thing, what is your object doing? For example, say you write an object that logs events to the winnt event log. Only power users and administrators can do this. On the identity tab, you must use a valid (and I recommend local) poweruser or admin account. For testing purposes, use oleview.exe but be aware that the instantiation occurs as the interactive user. No big deal unless you're calling your objects through a web server (which would run as the IUSR_webservername account).

Hope this helps!

- j