There are several factors determining which machine is the local master
browser for the subnet- but in general if you have one DC on the subnet
it should be the browser. I think the browser provides a list of file
and print shares. I don't think it is used for actually locating a
DC. (I could be wrong.) I think either WINS or broadcasts are used
for locating the actual server and other machines- including the DC
(for login) or the master browser (to browse file and print shares.)
I don't think the browser issue is relevant to the login issue.
"testparm -v" should verify that the machine is a DC.
"pdbedit -Lv" should show that accounts are setup.
Did you look at the event log in the Windows machine? They may show if
you are unable to locate an authentication server.
Are you able to put a Win machine on the same subnet as the working DC?
It may be quicker to head to your local computer supply store to replace
the bad RAM.
On 03/27/12 13:49, David Noriega wrote:
As I've been looking around the core issue seems to be that the domain
member, even though from its point of view, the BDC is the local
browser, it still uses the PDC to do authentication(ie turning up the
log level I only see 'check_ntlm_password' on the PDC)
On Tue, Mar 27, 2012 at 11:19 AM, Gaiseric Vandal
<gaiseric.van...@gmail.com> wrote:
To break the problem into 3 separate parts:
1. Logging in to a domain controller when the domain controller is on a
different subnet.
2. Accessing file shares when the domain controller is on a different
subnet.
3. LDAP backend.
1. Logging into the domain controller
If the clients don't have access to a WINS server (either a real wins server
or a proxy to a wins server) they won't be able to find the login server.
If you can enable the WINS server on the BDC, you can then configure your
windows clients IP settings to use the BDC's IP as the WINS server. it
isn't the recommended way to do it but it should help figure out if WINS
really is the issue.
"nbtstat -c" should show somthing like
MYBDC<20> ip.address.of.bdc
MYDOMAIN<1B> ip.address.of.bdc
MYDOMAIN<1C> ip.address.of.bdc
1B and 1C are browser and controller entries.
2. Accessing file shares
If you are browsing for file shares access as subnet, you will need WINS
access.
If manually try to connect via host name (e.g with the windows explorer OR
the "net use" or "net view" commands) WINS should not be is not needed but
DNS needs to be working. So exisiting connections, or connections mapped
via login script should be OK.
If connecting via hostname doesn't work, try connecting using the name of
the IP. (If the server has a name resolution issue, that could
potentially cause connection issues- unlikely but it happened to me once.)
3. Authentication
Samba doesn't actually care it the BDC and PDC use the same LDAP server(s).
You should use either the same LDAP server OR have LDAP servers that
synchronize, otherwise changes on one server are not replicated. But- in
terms of testing authentication if your user ids and passwords are the same
on both machines you probably don't need to worry about this for the moment.
But it will cause problems for you at some point.
On 03/27/12 11:49, David Noriega wrote:
The file shares are on a domain member. Is it that having the BDC as a
wins proxy and more importantly simply having wins on causing this
issue? We are on the university's network and they have their own wins
server for their own system wide windows domain. Our users primarily
logon from their office machines which are part of the university's
domain, not ours(which is only in our computer lab).
I'm just confused since the BDC has access to its own ldap server and
watching the logs when the setting is up high I see the domain member
which hosts the file shares is authenticating on the BDC. Yet why is
it when the PDC failed, users couldn't access their file share(which
yes is separate from logging onto a windows computer).
On Tue, Mar 27, 2012 at 5:33 AM, Jorell<jore...@fastmail.net> wrote:
On 3/26/2012 9:27 AM, David Noriega wrote:
Maybe my understanding is flawed but I thought the purpose of the BDC
was in the case of the PDC going offline, users could still use the
system. Just this morning our PDC failed with bad memory, yet users
were unable to map their network drive. The PDC is in our office while
the file server is in the server room where its been setup as a domain
member. On the server room subnet is its own BDC with its own ldap
server. Checking the logs I see that the server room BDC is listed as
the local domain server. The only thing that comes to mind is the BDC
does point to the PDC as the wins server. Is that the issue? Is there
a way around it?
The PDC/BDC controls logging onto the network.
Network file shares are different, what server was hosting the "network
drive"? If the PDC also hosted the network drive then they would also go
down.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
