Client/Server Setup: Non-Guest Account?

[anonim]

So after spending some time to tighten down security on my client/server setup (firewall settings, Windows user rights, share rights, etc), I pretty much had to open everything up in order to get the client and server to talk to one another.

From what I can tell, when the client attempts to access the "gbpvr" share on the server, it defaults to using the Guest account on the server. Therefore, I have to allow the server Guest account to allow the "log on over the network" user right as well as full permissions on the gbpvr program directory (and the recordings and livetv directories).

Typically, disabling the Guest account is one of the first things I do when I install Windows. Ideally, I prefer to create a locked-down user account on the server. I then want to be able to specify this account as the gbpvr logon account on the client configuration.

Is this possible in a workgroup (non-domain) environment?

[flyswatta]

Couldn't you use an account other than the Guest account? Like say, gbpvruser?

[psycik]

on your server machine create a gbpvr user give it what ever access. Set the gbpvr recording service to login as that account.

Then on your client, create the same user account with same password, and use that to login to the box.

Thats normally the easiest way

[anonim]

Yes, that's my plan. My question is whether this is possible to do on a client/server setup.. Nowhere on the client configuration settings do I see an option to specify the server logon account to use.

[sub]

The GBPVR.exe process on the client runs as the currently logged in user, so when it tries to access network shares it should be as that same user.

The Recording Service on the client runs as localsystem, but doesnt access the remote server.

[HtV]

The Recording Service on the client runs as localsystem, but doesnt access the remote server.

In fact you can stop it. It won't hurt. It'll start again though everytime you run/ok gbpvr-config.

[anonim]

The GBPVR.exe process on the client runs as the currently logged in user, so when it tries to access network shares it should be as that same user.

The Recording Service on the client runs as localsystem, but doesnt access the remote server.

Thank you, sub. So then, is the solution to create a username with the same password on both the client and the server and use this account? I'm not at home to try this right now, but I still don't think it would work.

Even though all the user specifies is the username, the PC name is embedded too. Therefore, when I try to authenticate from the client to the server with the same account username and password, it will fail, because the client will try to authenticate as HTPC\gbpvruser on the server, which will be expecting the account SERVER\gbpvruser. Since I'm not on a domain environment, these accounts will have different SIDs.

Is everyone who's using a client/server setup authenticating as Guest??

[nippywiffle]

If you go into my computer - tools - folder options - view, check that "use simple file sharing" is not selected on either PC, as this causes windows to always try to use the guest account to connect to other PCs.

You probably did this already, but just thought I'd suggest it... (it might not even be related)

[anonim]

Thanks nippywiffle, I've done this already.

By default, attempts to access file shares over the network use the currently logged on user's credentials. This works fine in domain environments, where the server can authenticate the requesting user through the domain controller.

However, when you're in a workgroup setup, the server cannot identify the user since that user only exists within the scope of the client machine. Therefore, it defaults to using the guest account, which means you must allow explicit rights for the Guest account (I hate doing that).

[nippywiffle]

I know what you mean, microsoft don't offer great support for workgroup networking... they don't realize that not everyone wants to run a domain in their house lol

You could always just map a drive to your server's c$ share, from the client, using a batch file at logon (ie a net use x: \\server\c$ /usererver\username password)
unfortunately that means the password is there in plain text...

I'm pretty sure that would give your client full access to the server using the account on the server.

I THOUGHT that if you set up the same username on the client that it should ignore which PC the account is located on and it's SID though...