实现安全稳固的AD和DNS架构
（AD出现问题50%是DNS所致，如果实现安全稳固的AD和DNS架构呢，下面是我的关于DNS和AD方面的笔记，希望对大家有所帮助，整理的比较乱，请大家谅解）
1、我们来回顾一下AD的安装验证
验证AD的安装
检查如下创建：
(1)、SYSVOL和共享
(2)、目录服务数据库和相关日志
(3)、默认活动目录结构
检查相关的事件日志
使用Dcdiag和Netdiag命令
SRV（服务资源记录）是服务和主机名之间做一个解析。
2、删除一台失效的DC，不能简单的把服务拿走，因为在其它的DC仍然保留着这台DC的信息。那么其它DC在复制的时候还会偿试着去找这台DC。
删除一台失效的DC
如果有两个DC，DC1和DC2，如果DC2坏掉了，如果不在DC1上删除DC2的相关信息，那么在数据复制时DC1还会偿试去联系DC2。那么就会出现复制错误，这是我们不愿意看到的。
如何在DC1上去删除DC2
不需要进到目录恢复模式，直接进到命令行。
使用ntdsutil这个工具
C:\>ntdsutil
ntdsutil:metadata cleanup(数据库的清理)
metadata cleanup:connections(进入到连接工具)
metadata cleanup:connections(进入到一个特定域控制器)
server connections:connect to damain lab.com（首先我连接到我这个域上）
server connections:connect toserver lab-dc1.lab.com(再连接到我这台服务器上)
server connections:quit(退到上一层目录)
netadata cleanup:slesct operation target(要指定那台DC无效了)
Slesct operation target:list current selections
Slesct operation target:list sites(要先看看当前计算机上都有那些站点)
Slesct operation target:select site 0(连接到其中的一个站点)
Slesct operation target:list servers in site(然后就可以看到有几台DC)
Slesct operation target:select server 1(1是代表坏掉的那台服务器)
Slesct operation target:list current selections
Slesct operation target:quit
Netadata cleanup:remove
Dcdiag和Netdiag进行检查，是否删除干净。
3、如果要实现安全稳固的AD和DNS架构我们必须先了解客户端是如何找到DC的?
当client想要登录到域中,他不并是直接找到DC,因为他并不知道谁是DC,那它会首先去查看DNS服务器,通过DNS解析SRV资源记录,他会向SRV记录去查询,谁是当前网络的DC,如果有SRV记录,client就会得到一个DC的地址,然后去访问DC.如果DNS里没SRV记录或SRV记录不正确,那么我们的client是无法联系到我们的DC的.
SRV叫服务资源记录,这种格式记录的意义在于,将我们计算机服务和主机名之间做一个解析.在DNS中的SRV记录是当每台DC在启动时,他会去注册自己的SRV记录.就是说:当管理员打开每台DC时,DC就会向他的DNS服务器去宣布我这台计算机究竟会做什么.他就会把他会做的写到DNS里去了.这样一个过程了.
4、如果想实现两台DC的冗余,那么两台DC都必须安装DNS服务,需要注意的是,DC1是AD的集成区域,那么在DC2上也建个AD的集成区域就可以了.
DNS的几个区域
主要区域:可以读可以写
辅助区域:为了实现冗余都会建好多辅助区域,辅助区域所有的信息都是从主要区域里复制过来的,如果主要区域坏了,辅助区域仍然可以提供查询,但不能再向区域里写任何信息了.所以微软在AD的布置当中,DNS即不用主要区域也不用辅助区域,用AD的集成区域,好处就是两台DC以后都同时是DNS,并且如果有某一台DNS发生了修改,DNS会去互相同步,也就是说,DNS从原来的主从关系,变成了现在这种平行的关系.到现在才可以说,我们的DNS是带有冗余的,还可以说不管现在的DC任何一台关掉,不会影响我的一个DNS应用.
5、我们再了解一下活动目录的维护
（1）AD数据库的修改过程(读写过程)
例：我们到AD上去添加个用户,修改等事件
它首先会把这个事件做一个初始化,并且把它写到内存里的一个缓冲区里,然后呢它并不是直接来写数据库(Ntds.dit),而是内存写好后它会去写EDB.log(每天发生的事,所做的事都会被EDB.log记住),写完EDB.log才会把事件写到AD数据库(Ntds.dit)里面去,之后这个事件会被写到另外一个文件也就是最后一个文件Edb.chk,当Edb.chk写完后,就认为这此的修改过程就完成了.
EDB.log and Ntds.dit那个文件会更大一些?
EDB.log会更大一些,例如,新添加一个用户XY,它会写到EDB.log里面,也会写到Ntds.dit中,但如果删除了XY这个用户,那么EDB.log里面还会写进XY这个用户被删除了,是一直增加的,而Ntds.dit在XY删除的时候,这条信息将被删除,数据库会减小.
EDB.log这个文件不会一直变大,只要写满了10M 就会自动改名为EDB000001.log（正常的做法是，我们把这个文件永久保存，但也可以把这个文件删掉）并释放一个空文件.
跟EDB.log一起还有两个文件res1.log和res2.log,是为了避免用户磁盘空间不够,倒至AD读写不完整,如果磁盘空间不够的话,AD首先会想到,把这两个文件删掉.删掉后又有了20M 空间,用这20M 空间去读写.
6、如何移动AD数据库和日志(在进行之间一定要把数据库做备份)
为什么会移动:1、磁盘空间不够了2、出于安全的考虑。
进行到目录回复模式
C:>ntdsutil
Ntdsutil:files(因为是对文件进行操作，所以要进入files模式的维护)
File maintenance:move db to d:\ad(把AD数据库移动到D盘下ad folder)
File maintenance:move logs to d:\ad(把AD日志文件移动到D盘下ad folder)
为什么这两个位置可以单独进行维护，我们在一个要求高可用性，高可靠性的AD当中，把AD中的DB和EDB .log分别存储在两个不同的磁盘上，或者不同的逻辑驱动器上，那么可以分别的对它们进行安全性的实施，另外一方面我们可以提高性能。
如何对AD数据库进行碎片整理. (在进行之间一定要把数据库做备份)
这个问题是很多人在做一个AD稳固过程当中，是一个比较容易忽视和忽略的一个问题，其实AD和磁盘一样，AD也会因为频繁的读写，高度负荷，产生一些碎片，也需要碎片整理的。（在一个服务器上会否经常的做磁盘的整理？不应该经常整理磁盘，如果你在服务器上经常整理磁盘的话，在整理的过程就会对你服务器的数据产生一个不好的影响，但是你对服务器的磁盘做了整理，仍然不能解决AD数据库碎片的问题，因为正常的磁盘整理，AD的数据库是不整理的）建议每年或每两年进行整理，但是必须做backup，因为这个整理是有风险的。
AD的整理其实就是把数据库全部copy出来，再重新去写一个文件。
进行到目录回复模式
C:>ntdsutil
Ntdsutil:files(因为是对文件进行操作，所以要进入files模式的维护)
File maintenance:compact to d:\ad(把AD数据库放到D盘的ad folder)
在D盘AD folder会产生一个新的整理后的数据库，然后把这个新数据库copy到原来数据库的位置，替换原来的文件。数据库会变小的，查询性能会变高的。
建议：在真实的环境中，不要同时做多个跟AD相关的管理工作，如果太多的话，会倒至AD出来故障。
7、AD数据库的备份
System state data
系统状态的备份是个非常重要的备份，我们的建议是我们每个服务器的管理员，都应该定期的每周去备份系统状态信息。大小在700M 左右。
Ntbackup（不用进入到目录还原模式）
操作主控的介绍
虽然有多台DC，但不是真的关掉那一台都可以。
为了避免两台都做主，某些工作必须由某一台来完成。
Schema Master（森林中的第一台DC）
AD最核心的就是schema master,如果不在了，就不能扩展schema master，就没法去装Exchange等了。
Domain naming master（森林中的第一台DC）
当我想住我的森林中添加一个域树或者添加一个子域的时候，那么Domain naming master负责去检查，你想要加进来这个域的名称和原来域的名称是不是有冲突的。如果有冲突，Domain naming master将拒绝新域的加入，如果它不在了，将倒至不能添加子域和域树的。
PDC Emulator（每个域的第一台DC）
1、域内的时间差不能超过5分钟，默认所有的 其它的DC还有client都会联系到PDC上去同步时间。
2、组策略为了避免冲突，必须在有PDC的时候才可以打开。
RID master每个域的第一台DC）
没有RID master我们的域是没办法去建用户的。
Infrastructure master每个域的第一台DC）
什么是权限委派？
1、 权限的分级管理
2、 通过委派实现
（1） 管理自治
（2） 服务的独立
用MMC为网管设计一个管理工具。
在建第二台DC的时候，就建一个跟AD一样的区域，然后打开AD集成动态更新，在DC同步的时候，他们就会自己同步了。
手动DC同步，在站点和服务上就可以让两台DC或多台DC进行同步。
1、我们来回顾一下AD的安装验证
验证AD的安装
检查如下创建：
(1)、SYSVOL和共享
(2)、目录服务数据库和相关日志
(3)、默认活动目录结构
检查相关的事件日志
使用Dcdiag和Netdiag命令
SRV（服务资源记录）是服务和主机名之间做一个解析。
2、删除一台失效的DC，不能简单的把服务拿走，因为在其它的DC仍然保留着这台DC的信息。那么其它DC在复制的时候还会偿试着去找这台DC。
删除一台失效的DC
如果有两个DC，DC1和DC2，如果DC2坏掉了，如果不在DC1上删除DC2的相关信息，那么在数据复制时DC1还会偿试去联系DC2。那么就会出现复制错误，这是我们不愿意看到的。
如何在DC1上去删除DC2
不需要进到目录恢复模式，直接进到命令行。
使用ntdsutil这个工具
C:\>ntdsutil
ntdsutil:metadata cleanup(数据库的清理)
metadata cleanup:connections(进入到连接工具)
metadata cleanup:connections(进入到一个特定域控制器)
server connections:connect to damain lab.com（首先我连接到我这个域上）
server connections:connect toserver lab-dc1.lab.com(再连接到我这台服务器上)
server connections:quit(退到上一层目录)
netadata cleanup:slesct operation target(要指定那台DC无效了)
Slesct operation target:list current selections
Slesct operation target:list sites(要先看看当前计算机上都有那些站点)
Slesct operation target:select site 0(连接到其中的一个站点)
Slesct operation target:list servers in site(然后就可以看到有几台DC)
Slesct operation target:select server 1(1是代表坏掉的那台服务器)
Slesct operation target:list current selections
Slesct operation target:quit
Netadata cleanup:remove
Dcdiag和Netdiag进行检查，是否删除干净。
3、如果要实现安全稳固的AD和DNS架构我们必须先了解客户端是如何找到DC的?
当client想要登录到域中,他不并是直接找到DC,因为他并不知道谁是DC,那它会首先去查看DNS服务器,通过DNS解析SRV资源记录,他会向SRV记录去查询,谁是当前网络的DC,如果有SRV记录,client就会得到一个DC的地址,然后去访问DC.如果DNS里没SRV记录或SRV记录不正确,那么我们的client是无法联系到我们的DC的.
SRV叫服务资源记录,这种格式记录的意义在于,将我们计算机服务和主机名之间做一个解析.在DNS中的SRV记录是当每台DC在启动时,他会去注册自己的SRV记录.就是说:当管理员打开每台DC时,DC就会向他的DNS服务器去宣布我这台计算机究竟会做什么.他就会把他会做的写到DNS里去了.这样一个过程了.
4、如果想实现两台DC的冗余,那么两台DC都必须安装DNS服务,需要注意的是,DC1是AD的集成区域,那么在DC2上也建个AD的集成区域就可以了.
DNS的几个区域
主要区域:可以读可以写
辅助区域:为了实现冗余都会建好多辅助区域,辅助区域所有的信息都是从主要区域里复制过来的,如果主要区域坏了,辅助区域仍然可以提供查询,但不能再向区域里写任何信息了.所以微软在AD的布置当中,DNS即不用主要区域也不用辅助区域,用AD的集成区域,好处就是两台DC以后都同时是DNS,并且如果有某一台DNS发生了修改,DNS会去互相同步,也就是说,DNS从原来的主从关系,变成了现在这种平行的关系.到现在才可以说,我们的DNS是带有冗余的,还可以说不管现在的DC任何一台关掉,不会影响我的一个DNS应用.
5、我们再了解一下活动目录的维护
（1）AD数据库的修改过程(读写过程)
例：我们到AD上去添加个用户,修改等事件
它首先会把这个事件做一个初始化,并且把它写到内存里的一个缓冲区里,然后呢它并不是直接来写数据库(Ntds.dit),而是内存写好后它会去写EDB.log(每天发生的事,所做的事都会被EDB.log记住),写完EDB.log才会把事件写到AD数据库(Ntds.dit)里面去,之后这个事件会被写到另外一个文件也就是最后一个文件Edb.chk,当Edb.chk写完后,就认为这此的修改过程就完成了.
EDB.log and Ntds.dit那个文件会更大一些?
EDB.log会更大一些,例如,新添加一个用户XY,它会写到EDB.log里面,也会写到Ntds.dit中,但如果删除了XY这个用户,那么EDB.log里面还会写进XY这个用户被删除了,是一直增加的,而Ntds.dit在XY删除的时候,这条信息将被删除,数据库会减小.
EDB.log这个文件不会一直变大,只要写满了
跟EDB.log一起还有两个文件res1.log和res2.log,是为了避免用户磁盘空间不够,倒至AD读写不完整,如果磁盘空间不够的话,AD首先会想到,把这两个文件删掉.删掉后又有了
6、如何移动AD数据库和日志(在进行之间一定要把数据库做备份)
为什么会移动:1、磁盘空间不够了2、出于安全的考虑。
进行到目录回复模式
C:>ntdsutil
Ntdsutil:files(因为是对文件进行操作，所以要进入files模式的维护)
File maintenance:move db to d:\ad(把AD数据库移动到D盘下ad folder)
File maintenance:move logs to d:\ad(把AD日志文件移动到D盘下ad folder)
为什么这两个位置可以单独进行维护，我们在一个要求高可用性，高可靠性的AD当中，把AD中的DB和EDB .log分别存储在两个不同的磁盘上，或者不同的逻辑驱动器上，那么可以分别的对它们进行安全性的实施，另外一方面我们可以提高性能。
如何对AD数据库进行碎片整理. (在进行之间一定要把数据库做备份)
这个问题是很多人在做一个AD稳固过程当中，是一个比较容易忽视和忽略的一个问题，其实AD和磁盘一样，AD也会因为频繁的读写，高度负荷，产生一些碎片，也需要碎片整理的。（在一个服务器上会否经常的做磁盘的整理？不应该经常整理磁盘，如果你在服务器上经常整理磁盘的话，在整理的过程就会对你服务器的数据产生一个不好的影响，但是你对服务器的磁盘做了整理，仍然不能解决AD数据库碎片的问题，因为正常的磁盘整理，AD的数据库是不整理的）建议每年或每两年进行整理，但是必须做backup，因为这个整理是有风险的。
AD的整理其实就是把数据库全部copy出来，再重新去写一个文件。
进行到目录回复模式
C:>ntdsutil
Ntdsutil:files(因为是对文件进行操作，所以要进入files模式的维护)
File maintenance:compact to d:\ad(把AD数据库放到D盘的ad folder)
在D盘AD folder会产生一个新的整理后的数据库，然后把这个新数据库copy到原来数据库的位置，替换原来的文件。数据库会变小的，查询性能会变高的。
建议：在真实的环境中，不要同时做多个跟AD相关的管理工作，如果太多的话，会倒至AD出来故障。
7、AD数据库的备份
System state data
系统状态的备份是个非常重要的备份，我们的建议是我们每个服务器的管理员，都应该定期的每周去备份系统状态信息。大小在
Ntbackup（不用进入到目录还原模式）
操作主控的介绍
虽然有多台DC，但不是真的关掉那一台都可以。
为了避免两台都做主，某些工作必须由某一台来完成。
Schema Master（森林中的第一台DC）
AD最核心的就是schema master,如果不在了，就不能扩展schema master，就没法去装Exchange等了。
Domain naming master（森林中的第一台DC）
当我想住我的森林中添加一个域树或者添加一个子域的时候，那么Domain naming master负责去检查，你想要加进来这个域的名称和原来域的名称是不是有冲突的。如果有冲突，Domain naming master将拒绝新域的加入，如果它不在了，将倒至不能添加子域和域树的。
PDC Emulator（每个域的第一台DC）
1、域内的时间差不能超过5分钟，默认所有的 其它的DC还有client都会联系到PDC上去同步时间。
2、组策略为了避免冲突，必须在有PDC的时候才可以打开。
RID master每个域的第一台DC）
没有RID master我们的域是没办法去建用户的。
Infrastructure master每个域的第一台DC）
什么是权限委派？
1、 权限的分级管理
2、 通过委派实现
（1） 管理自治
（2） 服务的独立
用MMC为网管设计一个管理工具。
在建第二台DC的时候，就建一个跟AD一样的区域，然后打开AD集成动态更新，在DC同步的时候，他们就会自己同步了。
手动DC同步，在站点和服务上就可以让两台DC或多台DC进行同步。
