Prevent DC from authenticating!!!

[TheMisio]

Ladies and Gents,

Does anyone know how to prevent a DC from processing logons?
We have got 5 DCs. One of the is on the remote site (as a DR system). It is alive, but I don’t want the server to authenticate users.
The server is on the same subnet as all the rest.

We use Windows 2003 system.

Any ideas?

Regards,

Michael

 

[itsp1965]

Have you tried creating a site for your subnet (you should have one by default) and indicating which DCs are part of this site. Users will most likely authenticate to the servers in the designated site

 

[TheMisio]

itsp1965,

I was thinking about removing the server from the site.
Should I create another Site (i.e. Failover Site) and move the DC to it?

Regards,

Michael

 

[Cstorms]

Typically AD sites and services is meant for situations like that where you have two physical locations, since client logons are site specific and from there more or less metric bound (unless you have configured your SRV records with goofy weights and priorities) I would say setup this server on a different subnet, move the DC to a different site and associate it with the new subnet, from here its a matter of routing.

Cory

 

[TheMisio]

Thanks Cstorms,

Different subnet is not an option (at least for now).

I’ve tried to configure the SRV records but on Priority not Weight... I didn’t work.
Which SRV record should I edit by the way. There are few:

DNS
My_domainzone
_TCP

Or

DNS
My_domainzone
_MSDCS
_DC
_TCP

....or which one actually (sorry but there are many SRV records within DNS pointing to the same DC)

And which record: LDAP?

Regards,

Michael

 

[itsp1965]

Mike is this server a global catalog server by any chance? You could also remove this role from this server, users would not be able to authenticate to it.

 

[Cstorms]

Just a note, messing with SRV records like that without having much of an idea on what effects it could have could hamper more then help, and even if you did configure them appropriately, this is still not a fullproof solution as its more of a preference then a requirement.

Cory

 

[kmcferrin]

So you have a single subnet that spans a WAN link to the remote site? Don't you find WAN congestion to be an issue?

Really, this is a textbook case of where separate subnets and AD Sites should be used. It's what they're designed for.

 

[TheMisio]

kmcferin,

I knpow it's a text book. I'm not that bad with AD.
The problem is that I have inherited the site. It has been set up with a DR system. The DR system is mirroring the real one. The problem is that people who set it up didn't think it through. Now at least for some time, I cannot mess too much with subnets. But the problem is that DR servers are authenticating. I can't get rid of them. I just need to make sure they will authenticate only if no other DC is available (failover).

Regards,

Michael.

 

[Cstorms]

Ok first off getting rid of the GC checkbox on this DC will not disable its ability to authenticate considering other DCs in this site should already hold a copy
.

http://technet2.microsoft.com/windo...d2a1-4e72-a54f-150483fa885a1033.mspx?mfr=true

Second, if you lack the ability to manage your network routing scheme then it may be necessary to simply have this machine in a cold state and manually replicate changes to it every so often (check your SLA requirements if this could even be an option). Like I said earlier you can modify the priority and weights of the specific SRV records that apply to this DC, however in a round robin query scenario such as yours this will not eliminate your problem... I may be missing something in my thinking but from where I stand right now, I would say that you can only ask the technology that you have to do so much.

Critique as needed, been a long day and I may be off base. Good luck.

Cory

 

[kmcferrin]

Yeah, that's pretty much what I'm getting at. It's like saying "I want to take my car through the car wash so that it gets clean, but I don't want it to get wet." The two are not mutually exclusive. I've ranted on similar issues in the past where people want the functionality that it designed into the OS but don't want the use the designed-in features to get it. You might find a solution that works, but you'll spend a lot of time beating your head against the wall and even then it won't work half as well as the intended solution.

That wasn't directed at you.

Sometimes being a good engineer/admin is knowing when to say, "This is wrong, we need to do it the right way, and if you're not willing to let me do it the right way then you're going to have to put up with things not working the right way."

So I'd go to the boss (or whoever is holding up the subnet change) and tell them that whoever designed the system didn't think it out, and that the subnet scheme needs to be changed to reflect Microsoft best practices for AD and network design, and that the issue with systems authenticating with remote DCs is a direct result of the network design NOT complying with best practices. The authentication issue that you're seeing isn't the problem. It is merely a symptom of the problem. The actual problem is that the network was implemented incorrectly. Fixing the symptom won't fix the problem, but fixing the problem will fix the symptom, and other symptoms.

In boss speak, "The system doesn't function correctly because it was implemented incorrectly. The way to make it function correctly is to correct the implementation.