Sign in
 
HomeWindows Server 2012Windows Server 2008 R2Windows Server 2003LibraryForums
Windows Server TechCenter >
> 
> 
Disabling Active Directory on a specific interface

Answered Disabling Active Directory on a specific interface

  • Friday, March 22, 2013 9:28 AM
     
     
    Sign In to Vote
    0

    Hello.

    Currently I have a Windows server 2008 R2 with active directory and 1 site running on 192.168.0.0/24 subnet. That is a main subnet that users log in. The server also has a second network adapter in 192.168.116.0/24 subnet. That subnet has it's own domain controller on linux. Is there any way to restrict active directory from sending network traffic to 192.168.116.0/24 but still be able to access shared network resources, as I get complaints from linux admin that active directory is causing conflicts with samba.

    Thank you.

     

All Replies

  • Friday, March 22, 2013 9:47 AM
     
     
    Sign In to Vote
    0

    Hi Anton,

    I can't imagine why that would cause a problem unless they share the same NetBIOS namespace and the Samba domain is relying to maintaining control of the browser function. It would be nice if the Linux administrator could actually clarify what the specific problem is.

    You'll need to know that anyway before we can hope to advise you specifically on which components to configure.

    In the absence of any specifics, all I can recommend at this point - based on the above speculation, is to create an outbound Windows Firewall rule that blocks perhaps some of the NetBIOS-related ports (UDP 137 and 138, and TCP 139) used in browser communcations.

    Cheers,
    Lain

     
  • Friday, March 22, 2013 10:03 AM
     
     
    Sign In to Vote
    0
    Seems like they do. The linux domain name is "tep" while ours is "aveva.tep". I'm not quite sure about domain configuration of the samba server. I'll currently just block the ports stated above until I get a more clear clarification of whats going on from the linux admin.
     
  • Friday, March 22, 2013 10:10 AM
     
     
    Sign In to Vote
    0

    No problem.

    Just one question though: Is aveva.tep your NetBIOS domain name or your DNS domain name - otherwise known as an FQDN? I would have thought it was your DNS domain name, in which case what you want to check (you can do this in many places, such as right-clicking on the domain node in Users and Computer and checking the Properties for the Pre-Windows 2000 name) is the value of the NetBIOS (listed as "Pre Windows 2000" in many of the MMCs) domain name. If that's also TEP, then maybe that's what's upsetting SAMBA.

    In any case, if the Linux admin comes back with something tangible instead of just waving their hands in the general direction of Active Directory, drop another post in here and we'll see what we can do to help.

    Cheers,
    Lain

     
  • Friday, March 22, 2013 10:19 AM
     
     
    Sign In to Vote
    0
    No, Pre-Windows 2000 name is simply "AVEVA" and FQDN is "SERVER.aveva.tep" so that does not appear to be a reason and should not cause any conflicts. I should definitely get in a closer touch with linux admin and get a more clear statement of what is going on.
     
  • Monday, March 25, 2013 7:55 AM
     
     
    Sign In to Vote
    0

    Hello,

    one big problem is to use a DC as a router, so use a real router. Multi-homing a DC result in multiple problems in the domain and should NEVER be done.

    In your situation, if the connection to the other network is required use a router and block all ports except the required ones to access the data on the shared folder.

    More better is to create a trust between the domains and configure the access that way.

    Best regards

    Meinolf Weber
    MVP, MCP, MCTS
    Microsoft MVP - Directory Services
    My Blog: http://msmvps.com/blogs/mweber/

    Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.

     
  • Monday, March 25, 2013 8:01 AM
     
     
    Sign In to Vote
    0
    No, other network is another department of our organisation but located in another building. The idea was to create a middle point that can be "seen" on both networks but separate the actual networks. Our PCs on 192.168.0.0/24 should be accessible to us only and vice versa.

     
  • Monday, March 25, 2013 8:08 AM
     
     
    Sign In to Vote
    0
    No, other network is another department of our organisation but located in another building. The idea was to create a middle point that can be "seen" on both networks but separate the actual networks. Our PCs on 192.168.0.0/24 should be accessible to us only and vice versa.

    Hello,

    the middle point between subnets is a router or layer3 switch BUT NEVER a DC.

    Best regards

    Meinolf Weber
    MVP, MCP, MCTS
    Microsoft MVP - Directory Services
    My Blog: http://msmvps.com/blogs/mweber/

    Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.


     
  • Monday, March 25, 2013 8:16 AM
     
     
    Sign In to Vote
    0
    Well, in theory yes. On practice we have limited budgets, already routed networks that can not be touched, etc. This was the only way we could do this in out situation.
     
  • Monday, March 25, 2013 8:19 AM
     
     
    Sign In to Vote
    0

    Hi Anton,

    Did you manage to get any feedback from the Linux administrator as to what he/she felt was going wrong? And has blocking the outbound browser traffic provided any relief?

    Cheers,
    Lain

     
  • Monday, March 25, 2013 10:47 AM
     
      Has Code
    Sign In to Vote
    0

    Yes. Here's what log says

    [2013/03/25 06:16:20,  0] nmbd/nmbd_browsesync.c:get_domain_master_name_node_status_fail(485)
get_domain_master_name_node_status_fail:
  Doing a node status request to the domain master browser at IP 192.168.116.100 failed.
  Cannot get workgroup name.

     
  • Monday, March 25, 2013 11:32 AM
     
     Answered
    Sign In to Vote
    0

    Okie dokie.

    I'm assuming 192.168.116.100 is your Windows AD host? If so, double-check you created the rule under the Outbound node and not the Inbound. If that's correct though, you still have two options:

    1. Create an inbound blocking rule with the same parameters (most importantly the Scope\Remote IP = 192.168.116.0/24).
    2. Disable the capacity to act as a browser host altogether.

    The "advantage" - if you want to call it that, of the first option is that the domain controller still maintains a browser list which will still feature on the other subnets (i.e. not the SAMBA subnet). Although, as someone who's been disabling this functionality since Windows 2000 was first released, I'd urge you to evaluate whether you even need it to begin with.

    The second option is easier to exploit, though it will require you to consider whether the functionality is needed at all, as there may well not be another host on the non-SAMBA networks capable of taking over the master browser role. In choosing this option, you will also be able to remove the Windows Firewall rules as they will no longer serve a purpose.

    Again, unless you have some seriously old applications (I'm talking from the 90s), I'm hoping you don't need this at all. In more recent version of Windows, the Computer Browser isn't used at all and the service is typically disabled. Windows these days uses something else called "network discovery".

    The steps for Option 2 are:

    1. Launch an elevated command prompt and run regedit.
    2. Navigate to HKLM\SYSTEM\CurrentControlSet\Services\Browser\Parameters.
    3. Change the value of "MaintainServerList" to No. If the value does not exist, create it as a "REG_SZ" value, then set the value to No.

    Cheers,
    Lain

    • Marked As Answer by Anton Borodyuk Monday, March 25, 2013 11:37 AM
    •  
     
  • Monday, March 25, 2013 11:40 AM
     
     
    Sign In to Vote
    0

    Thanks for a great detailed explanation. There's no reason for me to use Computer Browser as all of the PCs we are using are on Win7 and applications are all pretty modern.

    Marking this as solved.

    Thanks again.