Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
skipdogg
Nov 29, 2004
Resident SRT-4 Expert

I don't have a book to recommend, if you look for a network security book you're probably going to get something tailored to a Cisco environment that just deals with networking security issues. This is more of an overall 'best practice' area for general IT infrastructure.

To touch on a few things


Tequila25 posted:

I've been asked to redesign our network architecture for greater security

Any project should have clearly defined goals and objectives. What is the business trying to accomplish by having you do this? "greater security" doesn't really tell me anything. Are you worried about internal threats, external threats? Mitigating the spread of malware? Want to align with general best practices?

quote:

We are using a Sonicwall device as our main router/firewall. We have one subnet for servers and desktops, another for IP phones, and another for development servers, but they are not separated into security zones at all.

I'm not sure what you mean by security zones, maybe that's Sonicwall's terminology for something.

quote:

My plan so far is to separate the desktops into their own subnet, which should be easy because of DHCP. But we have public web servers and databases that have customer data. Should I put the web servers in a DMZ and databases in a seperate secure zone? Can print and file servers still be in the same zone as the desktops?

In my IT experience we've use different VLAN's, or subnets to logically organize and separate resources. Your environment sounds small, so I'm not sure how far you want to take this, but in the larger environments I manage we break down each particular site like so

Site - owns a entire class B network. 10.40.x.x addresses are used in Site A, 10.30.x.x addresses are used in site B. That way everyone knows if a resource has an IP of 10.30.x.x it's located physically in site B.

Each site is further broken up into standard vlan assignments. We use a /23 subnet on our internal network. VLAN 2 (10.30.2.x/23) is for servers, VLAN 4, phones, VLAN 6, workstations, VLAN8 resources like printers, VC units, etc. It's consistent across all sites. 10.30.2.x is a resource on the server VLAN in site B.

You can setup different ACL's to permit or deny access to resources. You could deny access to resources in 10.30.2.x from 10.40.6.x/23 if you wanted to. That's where some of the network security stuff comes into play. This is handled on your networking equipment usually.

Now with your publicly accessible resources, those should be located in a DMZ. You can read more about DMZ best practices on your own. Below is a pretty basic image of a DMZ so you can sort of get an idea about the purpose of it. Generally you want to segment off internet accessible resources from the rest of your network. Both firewalls should be locked down as tight as possible and only the specific ports needed for the service or resource being hosted.




This is a broad subject and covers several IT disciplines. There's a lot to learn and every environment is different. The first thing I would do if I were you is try to get a clear understanding of the goals of this exercise.

skipdogg fucked around with this message at 16:37 on Jun 30, 2015

Adbot
ADBOT LOVES YOU

BangersInMyKnickers
Nov 3, 2004

I have a thing for courageous dongles

I'm upgrading a 2003 domain to 2012R2 and there's some weird stuff going on with Netlogon/Sysvol DFS that is driving me crazy.

Currently DC layout is like this

DC1 2003
DC2 2012R2
DC3 2012R2

All three hold GC, DNS. DC2 holds all FSMO roles. The plan is for DC1 to be demoted, renamed, and offlined and DC3 will be renamed to take its place.

The part that is driving me crazy is when you browse the DFS properties of \\domain.local\sysvol namespace. If I do it from a Win7 or 2008R2 system or DC1 (2003 domain controller), all three DCs show up as active paths and I can check status and they come back OK. I can set any of them to active, write to them, and the files replicate out to the other two. Great, perfect.

When I look at the same \\domain.local\sysvol DFS properties directly from DC2 or DC3, only itself is displayed (DC2 only shows DC2 as a DFS path, not DC1 or DC3. Same issue on DC3 with its on name). From an elevated prompt or application I can still write files and they replicate pretty much instantly, so that looks good. Maybe its just design that 2012R2 DCs don't show other systems as possible DFS paths.

Looking at 2012R2 client systems, only a single DC path is populated to the namespace. It works correctly like everywhere else, but its concerning that I'm not seeing multiple ones there. Manually browsing to sysvol/netlogon from the hostname UNC to the DC works fine.

My fear right now is that DC1 is the only thing holding the namespace together and if I demote it sysvol implodes. I've run dcdiags and everything is coming back clean, so there's nothing in the logs to go on. One working theory I have is that this is an artifact behavior due to SMB1 being a deprecated feature in 2012R2 and bolt-on to the network stack. Since DC1 is SMB1 only and DC2/3 (and 2012R2 client servers) are native SMB2/3 with SMB1 fallback that the DFS paths not populating could be a fallback behavior for how it negotiates the different protocols. But I'm not finding any MS documentation to back that up, so I'm wary of going forward with pulling the plug on DC1.

If anyone has an thoughts on tests I should be doing or other tools to try, I would appreciate it. Thanks.

Dans Macabre
Apr 24, 2004


Tequila25 posted:

I'm a systems admin, and I've been asked to redesign our network architecture for greater security. We are using a Sonicwall device as our main router/firewall. We have one subnet for servers and desktops, another for IP phones, and another for development servers, but they are not separated into security zones at all.

My plan so far is to separate the desktops into their own subnet, which should be easy because of DHCP. But we have public web servers and databases that have customer data. Should I put the web servers in a DMZ and databases in a seperate secure zone? Can print and file servers still be in the same zone as the desktops?

I feel a little out of my depth here, and if someone could point me to a book or document with basic network security principles I'd appreciate it.

Knowing nothing else about your network I'd create different zones for the following for simplicity:

- LAN (internal servers, desktops, printers)
- DMZ (web servers)
- WAN (outside)

Your database server would be in the LAN most likely. Only put in the DMZ servers that must be accessed directly from the Internet. Your db server is probably not getting hit directly, but only getting called by the web server (which you would put in the DMZ). You only need to put the database server in a different zone if you don't want LAN users to see it, but you would create a new zone for that (like SECURE-LAN) rather than put the db server in the DMZ with the web server.


p.s. if you are the type of company that has a single sonicwall as your firewall you'll probably feel right at home with us in the small shop thread.

CLAM DOWN
Feb 13, 2007




I'm wondering if any of you have experienced this. Last month, MS released KB3061518:

quote:

This security update resolves a vulnerability in Windows. The vulnerability could allow information disclosure when Secure Channel (Schannel) allows the use of a weak Diffie-Hellman ephemeral (DHE) key length of 512 bits in an encrypted Transport Layer Security (TLS) session. Allowing 512-bit DHE keys makes DHE key exchanges weak and vulnerable to various attacks. For an attack to be successful, a server has to support 512-bit DHE key lengths. Windows TLS servers send a default DHE key length of 1,024 bits.

What this ended up doing, on a number of my systems, was break RDP. Setting the DHE group size back to 512 bits in the registry fixed this. I have yet to figure out the root cause of this, we have a LOT of custom GPOs and settings for SSL/TLS so I'm sure it's somewhere in our allowed ciphers list or something. Obviously I want it at 1024 bits, but I also need RDP working in the meantime.

Anyone else run across issues after this hotfix?

BangersInMyKnickers
Nov 3, 2004

I have a thing for courageous dongles

CLAM DOWN posted:

I'm wondering if any of you have experienced this. Last month, MS released KB3061518:


What this ended up doing, on a number of my systems, was break RDP. Setting the DHE group size back to 512 bits in the registry fixed this. I have yet to figure out the root cause of this, we have a LOT of custom GPOs and settings for SSL/TLS so I'm sure it's somewhere in our allowed ciphers list or something. Obviously I want it at 1024 bits, but I also need RDP working in the meantime.

Anyone else run across issues after this hotfix?

Check out what is being defined for schannel ciphers in your resultant GPO. You should have a lot of cipher overlap that would allow RDP over TLS without being dependent on that one cipher unless something is misconfigured.

CLAM DOWN
Feb 13, 2007




BangersInMyKnickers posted:

Check out what is being defined for schannel ciphers in your resultant GPO. You should have a lot of cipher overlap that would allow RDP over TLS without being dependent on that one cipher unless something is misconfigured.

That was the first thing I checked. We do restrict some ciphers, like for example, we don't permit anything using RC4/MD5, etc. There is nothing restricting the key exchange algorithm in any way though. Where does schannel determine this? As well, when allowed ciphers are listed, when you specify the KEA, you just specify the type of KEA in the cipher identifier and nothing to do with the key or group size. I cannot find any indication why 1024-bit DHE fails but 512-bit works.

BangersInMyKnickers
Nov 3, 2004

I have a thing for courageous dongles

CLAM DOWN posted:

That was the first thing I checked. We do restrict some ciphers, like for example, we don't permit anything using RC4/MD5, etc. There is nothing restricting the key exchange algorithm in any way though. Where does schannel determine this? As well, when allowed ciphers are listed, when you specify the KEA, you just specify the type of KEA in the cipher identifier and nothing to do with the key or group size. I cannot find any indication why 1024-bit DHE fails but 512-bit works.

I think multiple things are going on here. Can you post your schannel config? The corp schannel config I run on a predominately Win7/2008R2 network is this:

code:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA
The confusing bit to me about this is that schannel only supports standard DHE exchange for DSS/DSA sessions. Even with that above config, all my RDP sessions default to TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521, I assume because AD/kerberos/RDP over TLS only supports RSA-based ciphers which means ECDHE only, which should be completely circumventing the whole 512bit DHE issue.

What OS's are in play here? XP/2003 messes all of that up quite a bit because the schannel GPO's are Vista+ only.

hihifellow
Jun 17, 2005

seriously where the fuck did this genre come from

BangersInMyKnickers posted:

I'm upgrading a 2003 domain to 2012R2 and there's some weird stuff going on with Netlogon/Sysvol DFS that is driving me crazy.

Currently DC layout is like this

DC1 2003
DC2 2012R2
DC3 2012R2

All three hold GC, DNS. DC2 holds all FSMO roles. The plan is for DC1 to be demoted, renamed, and offlined and DC3 will be renamed to take its place.

The part that is driving me crazy is when you browse the DFS properties of \\domain.local\sysvol namespace. If I do it from a Win7 or 2008R2 system or DC1 (2003 domain controller), all three DCs show up as active paths and I can check status and they come back OK. I can set any of them to active, write to them, and the files replicate out to the other two. Great, perfect.

When I look at the same \\domain.local\sysvol DFS properties directly from DC2 or DC3, only itself is displayed (DC2 only shows DC2 as a DFS path, not DC1 or DC3. Same issue on DC3 with its on name). From an elevated prompt or application I can still write files and they replicate pretty much instantly, so that looks good. Maybe its just design that 2012R2 DCs don't show other systems as possible DFS paths.

Looking at 2012R2 client systems, only a single DC path is populated to the namespace. It works correctly like everywhere else, but its concerning that I'm not seeing multiple ones there. Manually browsing to sysvol/netlogon from the hostname UNC to the DC works fine.

My fear right now is that DC1 is the only thing holding the namespace together and if I demote it sysvol implodes. I've run dcdiags and everything is coming back clean, so there's nothing in the logs to go on. One working theory I have is that this is an artifact behavior due to SMB1 being a deprecated feature in 2012R2 and bolt-on to the network stack. Since DC1 is SMB1 only and DC2/3 (and 2012R2 client servers) are native SMB2/3 with SMB1 fallback that the DFS paths not populating could be a fallback behavior for how it negotiates the different protocols. But I'm not finding any MS documentation to back that up, so I'm wary of going forward with pulling the plug on DC1.

If anyone has an thoughts on tests I should be doing or other tools to try, I would appreciate it. Thanks.

I want to say you're seeing weirdness due to replication being handled by FRS (DFS-R can't be used unless the domain is at least at 2008) and I even think I remember seeing weirdness in the sysvol share before I switched replication over to DFS on our network but honestly idk. Can you copy them to a sandbox and see what happens when you pull dc1?

BangersInMyKnickers
Nov 3, 2004

I have a thing for courageous dongles

hihifellow posted:

I want to say you're seeing weirdness due to replication being handled by FRS (DFS-R can't be used unless the domain is at least at 2008) and I even think I remember seeing weirdness in the sysvol share before I switched replication over to DFS on our network but honestly idk. Can you copy them to a sandbox and see what happens when you pull dc1?

That's what it might come to, though management is breathing down my neck to be off 2003 yesterday. The 2003 box is physical and frail so it would probably be faster to throw together some fresh VMs and test it out there assuming nothing implodes. My plan for testing tonight is to shut down DC1 for about an hour and restart one of the 2012R2 non-DC servers and see what it sees on the namespace. If both DC2 and 3 show up then I'm going to stop being a baby and pull the trigger. If not, then its sandbox time.

CLAM DOWN
Feb 13, 2007




BangersInMyKnickers posted:

I think multiple things are going on here. Can you post your schannel config? The corp schannel config I run on a predominately Win7/2008R2 network is this:

code:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA
The confusing bit to me about this is that schannel only supports standard DHE exchange for DSS/DSA sessions. Even with that above config, all my RDP sessions default to TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521, I assume because AD/kerberos/RDP over TLS only supports RSA-based ciphers which means ECDHE only, which should be completely circumventing the whole 512bit DHE issue.

What OS's are in play here? XP/2003 messes all of that up quite a bit because the schannel GPO's are Vista+ only.

Windows 7 client/Server 2008 R2 server. I can't post our cipher list, but I can say that it's the same as yours with the exception that I have no P521 curve ciphers in the list, and SHA1/SHA256 only (no SHA384).

I agree that it should be using ECDHE only given these facts. You triggered something in my mind and I went to check our CA that issues certs for RDP used in this case. The CSP on the CA private key is RSA#Microsoft Software Key Storage Provider, aka not ECDSA_P***#Microsoft Software Key Service Provider. So, my certificates are not ECC certificates, correct? Could that be causing this?

Thanks for the help by the way! I do think I'm more familiar with SSL/TLS than a lot of people I've worked with, but this has been stumping me.

BangersInMyKnickers
Nov 3, 2004

I have a thing for courageous dongles

If you capture an RDP session in wireshark and tell it to decode as SSL it should spit out all the TLS handshaking and tell you exactly what is going on when it fails, what cipher it is using or at least attempting to use. That should be a good starting point.

Tony Montana
Aug 6, 2005

by FactsAreUseless

BangersInMyKnickers posted:

I'm upgrading a 2003 domain to 2012R2 and there's some weird stuff going on with Netlogon/Sysvol DFS that is driving me crazy.

Currently DC layout is like this

DC1 2003
DC2 2012R2
DC3 2012R2

All three hold GC, DNS. DC2 holds all FSMO roles. The plan is for DC1 to be demoted, renamed, and offlined and DC3 will be renamed to take its place.

The part that is driving me crazy is when you browse the DFS properties of \\domain.local\sysvol namespace. If I do it from a Win7 or 2008R2 system or DC1 (2003 domain controller), all three DCs show up as active paths and I can check status and they come back OK. I can set any of them to active, write to them, and the files replicate out to the other two. Great, perfect.

When I look at the same \\domain.local\sysvol DFS properties directly from DC2 or DC3, only itself is displayed (DC2 only shows DC2 as a DFS path, not DC1 or DC3. Same issue on DC3 with its on name). From an elevated prompt or application I can still write files and they replicate pretty much instantly, so that looks good. Maybe its just design that 2012R2 DCs don't show other systems as possible DFS paths.

Looking at 2012R2 client systems, only a single DC path is populated to the namespace. It works correctly like everywhere else, but its concerning that I'm not seeing multiple ones there. Manually browsing to sysvol/netlogon from the hostname UNC to the DC works fine.

My fear right now is that DC1 is the only thing holding the namespace together and if I demote it sysvol implodes. I've run dcdiags and everything is coming back clean, so there's nothing in the logs to go on. One working theory I have is that this is an artifact behavior due to SMB1 being a deprecated feature in 2012R2 and bolt-on to the network stack. Since DC1 is SMB1 only and DC2/3 (and 2012R2 client servers) are native SMB2/3 with SMB1 fallback that the DFS paths not populating could be a fallback behavior for how it negotiates the different protocols. But I'm not finding any MS documentation to back that up, so I'm wary of going forward with pulling the plug on DC1.

If anyone has an thoughts on tests I should be doing or other tools to try, I would appreciate it. Thanks.

You turn it off.

Whenever is the quietest time on your network, you shutdown the DC. If the sysvol DFS still works, great. If not, turn the DC back on. The reality is you can't completely clone the situation and there is always going to be an element of risk doing it in prod, that you can't eliminate in test.

Gyshall
Feb 24, 2009

Had a couple of drinks.
Saw a couple of things.

CLAM DOWN posted:

I'm wondering if any of you have experienced this. Last month, MS released KB3061518:


What this ended up doing, on a number of my systems, was break RDP. Setting the DHE group size back to 512 bits in the registry fixed this. I have yet to figure out the root cause of this, we have a LOT of custom GPOs and settings for SSL/TLS so I'm sure it's somewhere in our allowed ciphers list or something. Obviously I want it at 1024 bits, but I also need RDP working in the meantime.

Anyone else run across issues after this hotfix?

Yeah, it broke a ton of poo poo on my testing lab/workstation which is OK, but mainly because I can roll it back. We use a bunch of sites/services/webapps that do not conform to the TLS/SSL standards (weak encryption, etc.) The fix was to regenerate the SSL certificates in question with better ciphers/etc.

BangersInMyKnickers
Nov 3, 2004

I have a thing for courageous dongles

Tony Montana posted:

You turn it off.

Whenever is the quietest time on your network, you shutdown the DC. If the sysvol DFS still works, great. If not, turn the DC back on. The reality is you can't completely clone the situation and there is always going to be an element of risk doing it in prod, that you can't eliminate in test.

Yeah, I tried that two nights in a row. Rebooted 2012R2 clients and they were still seeing a single DC as a DFS path instead of DC2 and 3 like I was hoping.

hihifellow
Jun 17, 2005

seriously where the fuck did this genre come from
Was the DC they saw the one they authed against?

BangersInMyKnickers
Nov 3, 2004

I have a thing for courageous dongles

hihifellow posted:

Was the DC they saw the one they authed against?

No, there doesn't seem to be a pattern there. Logon server and the on DFS path seem to be distributed at random. Some will match, others won't.

BangersInMyKnickers
Nov 3, 2004

I have a thing for courageous dongles

Okay, built a test domain to run through the whole process. Same layout as the live domain, DC1 on 2003, DC2/3 on 2012R2. Joined 2008R2 and 2012R2 clients to the domain for testing the namespace.

Saw the same behavior with the 2012R2 DCs and clients not seeing more than one SYSVOL path despite 3 being up. Went blindly ahead demoting DC1 and raising functional level to 2012R2, behavior remained. Went through the FRS to DFS migration, behavior still persisted after a clean cutover.

Thankfully I can shut down the DC that a client is using as its namespace active host and at that point a second path will get populated and switched over so I'm not disrupting anything. I'm going to assume this is a bug in the 2012R2 dfs client. Not sure what else I can do here besides call MS for support, but this sure doesn't seem like an edge case and if it is a DFS client bug then someone else should have seen it by now.

e: And I built a fresh native 2012R2 domain with limited customizations, just vmware tools and disabling the IPv6 stack, and the same poo poo happened. I'm writing this off to lovely microsoft code.

BangersInMyKnickers fucked around with this message at 20:10 on Jul 2, 2015

KennyG
Oct 22, 2002
Here to blow my own horn.
Passwords! Passwords loving suck. I know there are products out there that can manage service accounts and password rotation for me but I can't find anything but manage engine and I have never had good luck with their stuff.

I want something to manage service accounts and share password access amongst admins. The overwhelming majority of our infrastructure is ad enabled. This is why I chose this thread.

incoherent
Apr 24, 2004

01010100011010000111001
00110100101101100011011
000110010101110010
Use managed service accounts?

vanity slug
Jul 20, 2010

KennyG posted:

Passwords! Passwords loving suck. I know there are products out there that can manage service accounts and password rotation for me but I can't find anything but manage engine and I have never had good luck with their stuff.

I want something to manage service accounts and share password access amongst admins. The overwhelming majority of our infrastructure is ad enabled. This is why I chose this thread.

KeePass? It's alright.

CLAM DOWN
Feb 13, 2007




KennyG posted:

Passwords! Passwords loving suck. I know there are products out there that can manage service accounts and password rotation for me but I can't find anything but manage engine and I have never had good luck with their stuff.

I want something to manage service accounts and share password access amongst admins. The overwhelming majority of our infrastructure is ad enabled. This is why I chose this thread.

Assuming your applications support them, managed service accounts are the way to go.

Maneki Neko
Oct 27, 2000

KennyG posted:

Passwords! Passwords loving suck. I know there are products out there that can manage service accounts and password rotation for me but I can't find anything but manage engine and I have never had good luck with their stuff.

I want something to manage service accounts and share password access amongst admins. The overwhelming majority of our infrastructure is ad enabled. This is why I chose this thread.

http://thycotic.com/products/secret-server/

or

http://www.liebsoft.com/Enterprise_Random_Password_Manager/

CLAM DOWN
Feb 13, 2007




I know this was a no-no in 2008 R2, but is it cool to do switch-independent/failover-on-fail NIC teaming on a 2012 R2 DC? I figured it would be fine with the new OS functionality. I know a LACP/load balanced team would be a bad idea, but the active/standby seems safe.

Tony Montana
Aug 6, 2005

by FactsAreUseless
No idea. Interested to know though. AD is a distributed system though, so losing a NIC on one of your DCs shouldn't mean a whole lot unless your network sucks.

CLAM DOWN
Feb 13, 2007




Tony Montana posted:

No idea. Interested to know though. AD is a distributed system though, so losing a NIC on one of your DCs shouldn't mean a whole lot unless your network sucks.

Yeah, this request came from one of our network guys, he has a hardon for teamed adapters on every server regardless of whether it's needed or not. I actually have never tried teaming on a DC so I figured I'll give it a try, why not.

Thanks Ants
May 21, 2004

#essereFerrari


Do you have any more info about the issues with LACP in 2008 R2?

Earl of Lavender
Jul 29, 2007

This is not my beautiful house!!

This is not my beautiful wife!!!
Pillbug
Quick sanity check, if you'd all be so kind: I'm considering running Server 2012 on a Pentium G3258 machine (at stock clocks), and using it as a Hyper-V host with a maximum of two concurrent guests. Am I literally insane? Would my next step up, an i3-4360, be more appropriate, or perhaps, still underpowered?

CLAM DOWN
Feb 13, 2007




Thanks Ants posted:

Do you have any more info about the issues with LACP in 2008 R2?

Using a load balanced team (ie. LACP) on a 2008 R2 domain controller can gently caress poo poo up, cause ntds.dit corruption, etc. Using it on a 2008 R2 member server is fine, just not a DC.. I never looked into the active/passive/failover teaming on 2008 R2 but I just stayed away from it. 2012 R2 has much better native NIC teaming functionality.

Dans Macabre
Apr 24, 2004


CLAM DOWN posted:

I know this was a no-no in 2008 R2, but is it cool to do switch-independent/failover-on-fail NIC teaming on a 2012 R2 DC? I figured it would be fine with the new OS functionality. I know a LACP/load balanced team would be a bad idea, but the active/standby seems safe.

maybe I'm missing something here but why would you do NIC teaming on Windows level rather than on vmware or hyperv host level

Zero VGS
Aug 16, 2002
ASK ME ABOUT HOW HUMAN LIVES THAT MADE VIDEO GAME CONTROLLERS ARE WORTH MORE
Lipstick Apathy
Is anyone else up on the Skype for Business Cloud PBX and Conference Call preview?

https://www.skypepreview.com/

It took me a few hours to figure it the gently caress out but now I have conference calls with the S4B meetings, and S4B itself making some high quality PTSN phone calls.

Tomorrow I'm going to see if I can get my Polycoms up on it.

Edit: You can give 100 users free local and international calling for 6 months with the trial.

Tony Montana
Aug 6, 2005

by FactsAreUseless

NevergirlsOFFICIAL posted:

maybe I'm missing something here but why would you do NIC teaming on Windows level rather than on vmware or hyperv host level

Well exactly, just present whatever your connecting to your DC (multiplexed optical connection running OSPF via the Moon) as a single TCP/IP Ethernet connection and all is well?

Anyways, thinking about it.. I've never seen DCs using teamed NICs. It's a distributed system, as I said, so you use teamed NICs in a situation where losing a NIC would mean losing the service. A SQL server with the db on it and it's a single point of failure, or perhaps in a cluster but there is only a couple of cluster members. But when you get into properly distributed systems.. you are replicating the whole infrastructure for redundancy. You're not just doubling up on NICs with Active Directory, but I want two beefy physical DCs per site and then a range of virtual ones for things like Exchange and the dev team to play with. I have over 25 domain controllers on my current network, multiple in each state and then I've got DCs in Hong Kong, Singapore and a bunch of other places.

So I guess I don't really care about NIC teaming for my DCs.. I put it together so we could lose entire sites (let alone a single NIC) and authentication (AAA) will be unaffected.

But yeah, good to know in 2012 it can be done. I'll keep it in mind if/when I'm asked.

edit: oh in response to the guy I quoted, because you'll find the core DCs are often still physical. Why? It's AD man, we're not resting everything on the virtulisation platform. AD is too important for a SAN to take a poo poo and a LUN be unavailable and oh no, noone can log in or do anything at all. If you're advanced enough to understand what GenerationID is and how it applies to modern virtualisation, then yes this can all be addressed, but chances are even if you know the actual deal with what Hyper-V can do (and now ESX has scrabbled to catch up) your organization doesn't :(

p.s. I am looking for another role now where the VMWare team understands this stuff..

Tony Montana fucked around with this message at 06:03 on Jul 8, 2015

CLAM DOWN
Feb 13, 2007




NevergirlsOFFICIAL posted:

maybe I'm missing something here but why would you do NIC teaming on Windows level rather than on vmware or hyperv host level

My DCs are physical.

Tony Montana
Aug 6, 2005

by FactsAreUseless
Let's talk some Enterprise Windows.. or more specifically.. what a career in this space means in 2015.

Globalization. Offshoring. Or as HP used to call it which made me shudder in my seat - bestshoring.

So my firm recently lost our contract with one of Australia's large networks(over 10k seats) to an Indian IT outsourcer. Their techs are not very good.

You see this in all aspects of our business, but in the Windows space it's particularly bad because 'everyone can do a bit of Windows, right?'.

Who has been affected by this? Who has interesting Knowledge Transfer stories to tell? Is becoming an Enterprise Windows guy a dangerous thing to do these days.. because you'll probably be replaced with someone that is paid a fraction of what you are?

BangersInMyKnickers posted:

Okay, built a test domain to run through the whole process. Same layout as the live domain, DC1 on 2003, DC2/3 on 2012R2. Joined 2008R2 and 2012R2 clients to the domain for testing the namespace.

Saw the same behavior with the 2012R2 DCs and clients not seeing more than one SYSVOL path despite 3 being up. Went blindly ahead demoting DC1 and raising functional level to 2012R2, behavior remained. Went through the FRS to DFS migration, behavior still persisted after a clean cutover.

Thankfully I can shut down the DC that a client is using as its namespace active host and at that point a second path will get populated and switched over so I'm not disrupting anything. I'm going to assume this is a bug in the 2012R2 dfs client. Not sure what else I can do here besides call MS for support, but this sure doesn't seem like an edge case and if it is a DFS client bug then someone else should have seen it by now.

e: And I built a fresh native 2012R2 domain with limited customizations, just vmware tools and disabling the IPv6 stack, and the same poo poo happened. I'm writing this off to lovely microsoft code.

I only just read this properly. I recently demoted out the last 2003 DCs out of a reasonably sized domain and had no problems with DFS. This lovely network couldnt tell me what was hardcoded to these DCs for DNS so I had to collect DNS logs and write Powershell scripts to parse them and reverse engineer what was hanging off these DCs and .. gently caress .. :(

Tony Montana fucked around with this message at 11:06 on Jul 8, 2015

Bob Morales
Aug 18, 2006


Just wear the fucking mask, Bob

I don't care how many people I probably infected with COVID-19 while refusing to wear a mask, my comfort is far more important than the health and safety of everyone around me!

Any suggestions on giving a user access to a folder or single file that's 5 folders deep in a folder they don't have access to, other than telling them to have someone else put that file in a different folder?

Tom from Engineering needs to be able to write to something like \Sales\Healthcare\Forms\Return Unit Authorization.doc

Tom's not in sales. Not going to get access to the sales folder. And I don't want to break inheritance etc doing a one-off on all the subfolders etc.

GreenNight
Feb 19, 2006
Turning the light on the darkest places, you and I know we got to face this now. We got to face this now.

The "best practice" way is to make an AD group that has the correct access, where the user can access the higher level folders but not see anything but the folder he has access too.



So you have to do that for Sales, and for HeathCare, then give him write access to Forms. PITA.

Erwin
Feb 17, 2006

Is he explicitly denied on all those folders, or just doesn't have rights? If the latter, can't you just give him modify on the file itself, and put a shortcut to it on his desktop? If he's explicitly denied, then yeah, you'd have to break inheritance.

wyoak
Feb 14, 2005

a glass case of emotion

Fallen Rib

CLAM DOWN posted:

My DCs are physical.
At my old job we used NIC teaming in failover mode (some servers going all the way back to 2003), but we always used the functionality built in to the drivers (so Broadcom or Intel's utilities). Broadcom's were a pile of poo poo and I convinced them to not bother on those, but Intel's utilities seemed to work pretty well.

Bob Morales posted:

Any suggestions on giving a user access to a folder or single file that's 5 folders deep in a folder they don't have access to, other than telling them to have someone else put that file in a different folder?

Tom from Engineering needs to be able to write to something like \Sales\Healthcare\Forms\Return Unit Authorization.doc

Tom's not in sales. Not going to get access to the sales folder. And I don't want to break inheritance etc doing a one-off on all the subfolders etc.
Move it to a different folder - having random poo poo several levels deep with different permissions is an auditing nightmare.

Bob Morales
Aug 18, 2006


Just wear the fucking mask, Bob

I don't care how many people I probably infected with COVID-19 while refusing to wear a mask, my comfort is far more important than the health and safety of everyone around me!

Erwin posted:

Is he explicitly denied on all those folders, or just doesn't have rights? If the latter, can't you just give him modify on the file itself, and put a shortcut to it on his desktop? If he's explicitly denied, then yeah, you'd have to break inheritance.

He's not explicitly denied, but I don't want to give him a shortcut for every file that he asks for access to.

vanity slug
Jul 20, 2010

Erwin posted:

Is he explicitly denied on all those folders, or just doesn't have rights? If the latter, can't you just give him modify on the file itself, and put a shortcut to it on his desktop? If he's explicitly denied, then yeah, you'd have to break inheritance.

Explicit Allow overrides inherited Deny, fyi

Adbot
ADBOT LOVES YOU

mayodreams
Jul 4, 2003


Hello darkness,
my old friend
Each of our locations has a physical DC with a teamed NIC mostly because they are the DHCP servers for the network as well. We are looking to abstract DHCP from DCs, and cluster it as part of our migration to 2012 R2.

For a standard DC, it is overkill, but in the past people threw all kinds of extra services on like Certificate Authority, TS/RDS licensing, etc. So sure you single connection goes down and authentication still happens, but those other services do not.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply