Windows: Logging on a service with a username from a remote computer

[trmiv]

I'm trying to get Act for Web setup here at work, and I'm running into a snag. Basically I'm running a web server on one computer (Windows 2003 standard), and our ACT database is on another computer. I found documentation on Act's site that shows how to set this up. At one point in their doc, I get to this point:

#Open the ActConn service properties, Under the Log On tab, enable the This account option.
# If you are on a peer-to-peer network with no domain, enter the name of the computer hosting the remote database, followed by a backward slash and your user name. For example, if the computer hosting the database is named SALESPC, and your username on that computer is tdurden, enter salespc\tdurden. Take note that as a prerequisite, that share will need to be pre-configured to allow this user to have full control over it.
- or -
If the computer hosting the remote database is in a domain, enter the domain name, followed by a backward slash and your user name. For example, SALES\tdurden. Note that you will also need pre-configured permissions on this share.

Now, when I enter the name of the remote PC, a slash, then the user name, it always just says that the account name is invalid or does not exist. I know this account exists on the remote computer. I also know the web server is able to log into the remote computer. Am I missing something here? Is there some kind of group policy setting I have to enable to be able to make a service log on with an account from a remote computer? Keep in mind this is a peer-to-peer network.

 

[trmiv]

Anyone? I'm almost certain this won't work in a peer-to-peer environment. As far as I know, you cannot use a log on from another computer to start a service in a peer-to-peer network. ACT! tech support claims you can. Can anyone verify this for me?

 

[sciencewhiz]

ACT doesn't use a real database program on the computer that hosts the database. Rather, it opens up the file(s) via windows file sharing, and does all the database stuff on the computer running ACT. To windows, it looks like any other program accessing a remote share. There is no service to start.

To be able to share files in a NT based operating system, the person accessing the share must have a valid local login. You can either use an existing one, or make one up and add that user.

 

[bsobel]

Originally posted by: trmiv
Anyone? I'm almost certain this won't work in a peer-to-peer environment. As far as I know, you cannot use a log on from another computer to start a service in a peer-to-peer network. ACT! tech support claims you can. Can anyone verify this for me?

I think they meant to say choose an account with the same name/password as on the other machine (in the p2p case). Since your are setting the services credentials you can't supply one from another workgroup member, there is no trust relationship.

If you use the default SYSTEM account, it doesn't have rights to pass traffic thru the redir, hence you need a local account. If the local account you use can see the remote share, you should be fine.

Bill

 

[trmiv]

Originally posted by: sciencewhiz
ACT doesn't use a real database program on the computer that hosts the database. Rather, it opens up the file(s) via windows file sharing, and does all the database stuff on the computer running ACT. To windows, it looks like any other program accessing a remote share. There is no service to start.

To be able to share files in a NT based operating system, the person accessing the share must have a valid local login. You can either use an existing one, or make one up and add that user.

I'm not talking about the regular ACT for windows, I'm talking about ACT for Web. Act For Web allows people to view your act database over the internet. We have an ACT database here at work we all access, but we have a remote office that needs one person to be able to access it. So we bought Act for Web to do that. In the Act for Web product there is a service called ActConn.

I think they meant to say choose an account with the same name/password as on the other machine (in the p2p case). Since your are setting the services credentials you can't supply one from another workgroup member, there is no trust relationship.

If you use the default SYSTEM account, it doesn't have rights to pass traffic thru the redir, hence you need a local account. If the local account you use can see the remote share, you should be fine.

Tried that as well, no go. I actually called ACT support and went over this with them, quoting their exact support doc which says how to do this, and they were stumped as well. The ACT support guy was completely confused when I said I created an account on the web server with the exact name of an account on the computer with the ACT database on it. He was like "why would you do that?"


Here is their exact document I followed for this step 5 will just not work:

llow the procedure below to configure ACT! for Web to connect to a remote database residing on your Local Area Network:

Note: If you are going to configure ACT! for Web to access multiple databases, please take the time to delete the shortcuts to the "ACT! for Web Database Selection" utility from your desktop and Start Menu. This tool is only for use with a single database on a single website, and can cause ACT! for Web to stop functioning if more than one database is configured.

1. On the remote PC, share the folder that contains the remote database.
2. On your ACT! for Web server, edit (using Notepad) the file global.asa in your installation directory, and modify the following fields as shown:
* recApp.Fields(?DBPath?).Value = ?drive path of database? ? DB_PATH
* recApp.Fields(?DBName?).Value = ?database name? ? DB_NAME
* recApp.Fields(?ACC_DB?).Value = ?mdb path? ? gACC_DB
* recApp.Fields(?locale?).Value = ?locale?

Note: The database path and mdb path must be entered using Universal Naming Convention (UNC). For example, if your remote database is named "Contacts" and located in the ?sales? shared folder on a server called ?SALESWEB?, you would enter the database path as \\SALESWEB\sales. Please see the example below:

recApp.Fields(?DBPath?).Value = ?\\SALESWEB\sales? ? DB_PATH
recApp.Fields(?DBName?).Value = ?contacts? ? DB_NAME
recApp.Fields(?ACC_DB?).Value = ?\\SALESWEB\sales\contacts.mdb? ? gACC_DB
recApp.Fields(?locale?).Value = ?US?

1. Right-click the My Computer icon, then click Manage from the shortcut menu. The Computer Management dialog appears.
2. Click the plus sign to expand the Services and Applications menu, and then click Services.
3. Right-click the ActConn service, and then click Properties from the shortcut menu. The ActConn Properties (Local Computer) dialog appears.



4. Under the Log On tab, enable the This account option.
5. If you are on a peer-to-peer network with no domain, enter the name of the computer hosting the remote database, followed by a backward slash and your user name. For example, if the computer hosting the database is named SALESPC, and your username on that computer is tdurden, enter salespc\tdurden. Take note that as a prerequisite, that share will need to be pre-configured to allow this user to have full control over it.
- or -
If the computer hosting the remote database is in a domain, enter the domain name, followed by a backward slash and your user name. For example, SALES\tdurden. Note that you will also need pre-configured permissions on this share.
6. Enter your password in the appropriate fields, and then click OK.

Important Note: Since the Internet Guest Account (IUSR_WEBSERVERNAME) is no longer able to be used for the authentication on another computer, the account used above must also be used in the ACTWEB virtual directory properties:



7. AT the Computer Management window, click the plus sign to expand Internet Information Services. Navigate to the website on the list where the actweb virtual directory is located. Right click on that virtual directory, then click Properties. The ActWeb Properties dialog appears.
8. Under the Directory Security tab, in the Anonymous access and authentication control section, click the Edit button. The Authentication Methods dialog appears.



9. Check Anonymous access box, then click Edit.The Anonymous User Account windows appears.



10. Enter the User name and Password being used to access the ACT! Database across the network. Make sure you clear the Allow IIS to control password check box.

Important Note: Since the Internet Guest Account (IUSR_WEBSERVERNAME) is no longer able to be used for the authentication on another computer, the account used above must also be used in the ACTWEB virtual directory properties.


You will now be able to access your ACT! Database remotely.

 

[SoulAssassin]

It's a kluge but setup an account on the local machine that has the exact same user name/pwd as the one on the remote machine. Run the service as the local acct.

 

[bsobel]

Originally posted by: SoulAssassin
It's a kluge but setup an account on the local machine that has the exact same user name/pwd as the one on the remote machine. Run the service as the local acct.

Thats what I said before, he indicated it didn't work however....
Bill

 

[SoulAssassin]

Originally posted by: bsobel

Originally posted by: SoulAssassin
It's a kluge but setup an account on the local machine that has the exact same user name/pwd as the one on the remote machine. Run the service as the local acct.

Thats what I said before, he indicated it didn't work however....
Bill

Yup, blew right past that one.

It should work, make sure you can map to the share on the other box normally before trying to do it as a service. Might be worth adding both accts to their respective admin groups. Shouldn't need to since it grants SeLogonAsService rights when you modify the service.

trmiv - when you say it's not working, exactly what is/isn't working? Will the service start? Does it start but can't access the web server? Does magic smoke escape from the processor?

 

[trmiv]

Originally posted by: SoulAssassin

Originally posted by: bsobel

Originally posted by: SoulAssassin
It's a kluge but setup an account on the local machine that has the exact same user name/pwd as the one on the remote machine. Run the service as the local acct.

Thats what I said before, he indicated it didn't work however....
Bill

Yup, blew right past that one.

It should work, make sure you can map to the share on the other box normally before trying to do it as a service. Might be worth adding both accts to their respective admin groups. Shouldn't need to since it grants SeLogonAsService rights when you modify the service.

trmiv - when you say it's not working, exactly what is/isn't working? Will the service start? Does it start but can't access the web server? Does magic smoke escape from the processor?

Here's what I did. I created an account on the server containing the Act data file called "test", with the password of "test". I also created an account on the web server with the same username/password. On the machine with the Act data file I shared the Act data folder. I specifically gave the "test" user full control of this folder. Now, if I go on the web server and browse to the Act data folder on the Act computer, I can open it without it asking for a username and password. Then on the web server I told the ActConn service to log on using the "test" account (The "test" account on the web server, it of course will not take the "test" account from the Act computer).

Finally, in IIS, I went as far as to say the anonymous user for the act website is this "test" user. So, now everything using Act is now using this "test" user. Finally I try to log into my act website, it opens the act page, says it's creating the connection, and then bombs out with the following error:

Error on ACT! for Web Application:
Error Description = Registration is required to use ACT! for Web.
For a 30-day trial version of this product, click Try it

If you have purchased ACT! for Web, type the serial number provided, and then click Submit.

Now, there are no buttons, no links, nothing to click on this page. According to Act, if there are no buttons on links to click when this message comes up, there is a permissions problem. According to them, the problem is because the ActConn service is not logged in in with the username from the computer which contains the Act data file. So, according to ACT (see their doc above), I should be able to go on the web server, open the ActConn service, and tell it to log on using the following name: (the computer containing the act data file is called SAKAI) SAKAI\test. Of course, this won't work because the web server is not going to be able to use an account from another computer to log on a service.

Keep in mind, if I take my act data file and actually put in on the web server machine, I don't have this problem, everything works as advertised. So the problem is obviously a permissions problem between the web server and the computer with the data file. According to Act, logging on the ActConn service with the computername\username from the computer containing the act data file will fix this problem. Only problem is, that is not possible in a peer-to-peer environment like they claim it is.

Just for reference, the computer with the act data file is a Windows 2000 Advanced server machine, the web server is a Windows Server 2003 standard machine.

I'm at my wits end with this. I absolutely hate ACT, but my company uses this and my boss has put me in charge of "making this work",

 

[SoulAssassin]

Changing database folder security permissions

You must give the IIS User full access to both the Share and the Security of the database folder where the ACT! database is located. It is not sufficient to include a group that the IIS user is a member of; you must explicitly identify the IIS user in both the Share and the Security of the database folder. Also, if you have setup the database for Shared Folder synchronization, the IIS User must have full control of this folder as well

Try running IIS as the same acct just for ishts and giggles.

 

[trmiv]

Originally posted by: SoulAssassin

Changing database folder security permissions

You must give the IIS User full access to both the Share and the Security of the database folder where the ACT! database is located. It is not sufficient to include a group that the IIS user is a member of; you must explicitly identify the IIS user in both the Share and the Security of the database folder. Also, if you have setup the database for Shared Folder synchronization, the IIS User must have full control of this folder as well

Try running IIS as the same acct just for ishts and giggles.

Did that, no go.

How about this, ACT elevated me to their second level support, saying this is the first time anyone has called with this issue. They apparently tested it out for me to see if they could get it to work. According to them, they setup a small peer-to-peer enviroment and were able to log on a service with an account from another machine! They were even given the other machine as a choice when they used the "browse" button when selecting the log on. So now they say I should call Microsoft. Now, I'm totally stumped.

 

[SoulAssassin]

Originally posted by: trmiv
Now, I'm totally stumped.

That makes two of us.