[pptp-server] quick question about file sharing and vpn

[Jose M. Sanchez]

|
|I just setup poptop and I must say it really kicks some major a**, but I
|have one little problem. The boss said he wanted the vpn server to allow
|our sales people to login to our nt server which is a pdc. I setup the
|chap-secrets file like so:
|DOMAIN\\test    *    test *
|
|I even setup the pdc with the account. I tried it on the LAN and logged
|in just fine.
|
|now, after playing with it, I figured this out. if I go into network
|properties on win98se and setup a domain in client for Microsoft
|networks, I can get on the domain, but here is what I have to do. I have
|to restart and login to the domain. of course it takes 30 seconds cause
|the system can't find the domain. I login anyway and it tells me that
|some features may not be accessible because no domain was found. then I
|connect with ms vpn to my Linux box and I can access the pdc's file
|shares just fine.
|
|the question really is, is there a way to get a domain login after I
|connect to my Linux box via vpn or can I get samba on the Linux server
|to start the prompt. by the way, I don't have samba setup currently and
|if this matters, I don't think I setup the wins server yet on either the
|Linux box or nt.
|
|any ideas, comments, or how-tos are much appreciated, rage-dca.
|

Well I hope someone corrects me if I'm wrong on this, but here goes.

As I understand it domain logins do work. At least they seem to work for me.

I have chap-secrets set up like this (and nothing else, contrary to the
docs...)

remote          *               pass          *

and options like this

debug
auth
remotename remote
require-chap
proxyarp
+chapms-v2
+chapms
mppe-40
mppe-128
mppe-stateless
ms-wins 192.168.0.6
ms-dns 192.168.0.6
lock

The debug messages (I turned on verbose) indicate that the login name
entered into Windows DUN VPN dialup entry is being passed to the PPTP
client.

Thus if the Windows DUN entry has; username: admin password: pass

"admin" is suffixed onto the name of the DOMAIN the remote client belongs to
(when you created the DUN entry) and then passed to the PPTP client...
supposing that in this case the domain is called "Mydomain"...

The debug logs show that pptp receives Mydomain\\admin which is used to
authenticate the client. This also supposedly gets passed onto the domain
controller when ppp is brought up.

Thus because the name of the remote client is "forced" in the option file,
it does not matter what it's called.

However the password (in this case "pass") is getting picked up from the
chap-secrets file, and NOT by what the user types in... (I've tried "*" in
the password field, which does not work from me...).

By making the two the same as what the domain is expecting for the user, you
get a domain logon.

I've also enabled "network logon" in the DUN entry.

It -SEEMS- to work, as I can attach to any shares, and I seem to have the
correct permissions.

I can also browse the remote network... BUT here is the caveat with this.

The Windows CLIENT machine -MUST- have originally been set up to belong to
the SAME domain as the one you are trying to connect to... at the time
Networking was first installed.

If you enter another domain, switch it to the correct one, then set up
DUN... you'll never see the remote shares!

To fix this you must remove ALL networking components in Windows (including
protocol.* files in the C:\Windows directory) then re-install everything,
specifying the appropriate domain name.

If you do this browsing works!

I've gone as far as checking to see what is happening in the registry...
among other things windows INCLUDES the original domain name in the registry
entry created for the DUN... even if you have changed it!

This in turn gets passed to the remote PDC. Since it sees that your machine
is not a member of your domain, you do not see the shares.

Fixing the DUN entry in the registry (which I've done) is not enough of
itself to browse the remote LAN...

You must do what I mentioned before, deleting all Networking setups, and
then re-install (after a reboot, this is windows folks...) using the correct
domain name.

Finally set up your dun entries. Doing things this way, always gets me the
browse lists off the remote LAN.

If you then change the client's domain membership, you start all over
again... and you have to fix it again... though you DO seem able to merely
switch the domain name to get VPN working properly...