> Im trying to join one NT Server 4.0 Remote Access Server to a samba PDC
> (2.2.2) Domain so that the users who make dial-up connections can be
> validated on this domain. The Windows NT Server (RAS) is joining to the
> domain but the users who trying to make a dial-in connection receive a
> message saying that they not have permission to make a dial in connection.
> Must I configure anything in the smb.conf file
We tried to do something similar here (We have a Samba PDC, DNS, and DHCP
server, and a Win2K VPN/RAS server). We couldn't get it to work completely,
but got enough functionality to make it useful.
First we tried to use the Samba PDC to authenticate logins, but it didn't
work. So instead, we set up special local user accounts for the VPN users on
the NT RAS server, and authenticated against them instead.
This means that the computer is part of our private TCP/IP network, but not
logged on to the domain directly.
Here is part of a document that my colleague wrote describing work arounds
for the problems that this causes:
Connection Problems
1/ Can't resolve any .private.activenavigation.com DNS names, or even other
normal DNS names.
This looks like a Windows 2000 bug or limitation.The problem is as follows:
Your PC dials up using a modem. The DNS servers specified in the dial-up
connection take precedence.
You then dial up to the VPN. The DNS servers specified in the VPN dial-up
connection do NOT take precedence over the existing ones.
Any query to the *.private.domain.com domain will fail, as this domain is
not published on the Internet.
However, the dnslookup tool seems to work fine.
To work around this issue, after you connect to the VPN, restart (or simply
stop) the "DNS Client" service, and all application DNS queries will
work as
expected. After this workaround, I've seen DNS problems before connecting to
the VPN, even after rebooting the machine, so you may want to set the DNS
Client service to "manual" start-up.
For more information about the DNS Client service, see Microsoft article at
http://www.microsoft.com/windows2000/en/server/help/sag_DNS_ovr_ClientFeatur
es.htm?id=1942
Other workarounds are:
Use the IP address rather than the DNS name, which is cumbersome but it
works!
Use the following command to find out the IP address from a DNS name:
nslookup name_to_look_up 192.168.1.2
Where 192.168.1.2 is the internal DNS server that knows about the
.private.domain.com domain.
Add to your \winnt\system32\drivers\etc\hosts file mappings between names
and addresses, to make it less cumbersome.
2/ Can't join the DOMAIN domain.
Joining the DOMAIN domain from the home PC would provide benefits when
accessing file and printer shares. However, the NT 4 laptop we've got in the
office cannot join the DOMAIN domain through the VPN tunnel, although it can
when plugged directly into the internal network. I couldn't join the domain
with my Windows 2000 computer at home. Any more information on this will be
appreciated.
3/ Difficulties accessing Windows file or printer shares or seeing other
Windows machines on the network.
Use the following workarounds:
net view /domain:DOMAIN
Lists all computers in the DOMAIN domain. Useful, as no machines are
normally visible in the Network Neighbourhood.
start \\computer_name
Opens a window that, after some time, will prompt for login and password for
that computer. Simply enter "DOMAIN\your_login" as login to access the
machine.
Instead of the computer name, you can also type the fully-qualified DNS name
or its IP address.
When the target computer is pdc1 (the main domain server), it takes a long
time for Windows to ask for the login and password. Pending further
research.
net use \\computer_name /user:DOMAIN\your_login
Similar to start \\computer_name , but faster to ask for password. This
caches the login credentials, so afterwards opening that computer is faster
and doesn't need authentication.
Type "net use" to see the active connections, and "net use
\\computer_name
/delete" to remove the entry from the active cache.
If none of the above works, check out Microsoft article Q301337, about a
problem introduced in Windows 2000 SP2.