实现安全稳固的AD和DNS架构

实现安全稳固的 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 进行同步。