Re: Is the PDC always needed?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Users typically are not on any subnet that has our PDC or BDC nor can
they browse for their share. They are directly connecting by giving
the full hostname of the server such as \\server.x.x.x\sharename by
using the map network drive dialog in windows.

On Tue, Mar 27, 2012 at 1:27 PM, Gaiseric Vandal
<gaiseric.vandal@xxxxxxxxx> wrote:
> Ah.  I wasn't clear on the domain authentication issue.
> Are users unable to see shares?  Or are they just unable to authenticate to
> them once they see them.
>
> Also, just to clarify, were the users on the same subnet as the PDC but not
> the BDC?
>
>
>
>
>
> In smb.conf, verify that the following is set:
>
>        security=user
>
>
> You can use the "smbclient -L" command on your BDC to verify the credentials
> for a windows user.
>
> On windows machine, you can use the following to verify credentials:
>
>    "net use \\theserver /user:yourname"
>
>
> Assuming credentials are OK, users will still need to use wins to browse
> resources not on the same subnet (unless the specifically map drives on IP
> or hostname)
>
>
>
>
>
>
>
>
> On 03/27/12 14:16, David Noriega wrote:
>>
>> The users of our service are on windows machines that are typically
>> not on our subnet or part of our domain. They simply use windows 'map
>> network drive' function to get to their share.
>>
>> On the BDC, yes testpart reports ROLE_DOMAIN_BDC and pdbedit does list
>> all of our users.
>>
>> Maybe this is part of my misunderstanding, but does the windows
>> machine need to know of the BDC(which they wouldnt as the user is
>> typically on a different subnet)? If they are using the hostname of
>> the file share server, then isnt authentication happening on that
>> server? Users are not logging onto our domain on their machines,
>> simply accessing their share.
>>
>> On Tue, Mar 27, 2012 at 1:01 PM, Gaiseric Vandal
>> <gaiseric.vandal@xxxxxxxxx>  wrote:
>>>
>>> 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.vandal@xxxxxxxxx>    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<JorellF@xxxxxxxxxxxx>
>>>>>>  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
>>
>>
>>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba



-- 
David Noriega
System Administrator
Computational Biology Initiative
High Performance Computing Center
University of Texas at San Antonio
One UTSA Circle
San Antonio, TX 78249
Office: BSE 3.112
Phone: 210-458-7100
http://www.cbi.utsa.edu
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba



[Linux]     [Info Cyrus]     [LARTC]     [Bugtraq]     [Netfilter]     [Internet Dating Forums]     [RAID]     [Yosemite News]     [Photography]

Add to Google Powered by Linux