訪問控制層安全設置
對於DNS管理來說
使用windows
DNS進行安全更新的真正的問題在於LDAP協議對於DNS記錄更新的成敗
必須理解windows 安全許可和所有權函數是如何規范的
因為正是它們掌握著更新的成敗
如果理解了對於域區和域區數據的缺省設置是什麼以及缺省是如何調節的
就可能在缺省配置之外管理動態更新了
這一節試圖讓這個問題變得盡量簡單
並且假設對前述內容有了一定的背景知識
對windows 安全概念有大體的理解
包括對訪問控制列表和所有權的大致了解
缺省的Out
of
the
box配置使得授權用戶組的任何成員在任何域區裡創建記錄
如A記錄或PTR記錄
當一個記錄存在後
它能被
Everyone
組裡的任何一個成員訪問
但也許只能被最初創建者
或者被不同類型的管理員
或者被系統本身所修改
在很多情況下
這種改變和刪除已存在目錄的
創建後
限制提供了一個可取的行為
但有些時候它又會帶來問題和產生舊記錄
圖
顯示了一個集成域區的缺省安全設置
注意圖
給出了一個域區
而不是一個資源記錄
Everyone
組是高亮度的
表明了這個組被授予了特殊的配置允許
位於它正上方的
AuthenticatedUsers
組表明了它被允許創建所有的子目標（這種情況下為資源記錄）
授予
Everyone
組的特權賦予域區本身的讀取訪問權
包括列表權
圖
顯示了同一個域區
使用DNS服務器管理控制器而不是圖
中的活動目錄用戶和計算機控制器
圖
中編輯器打開指定給
Everyone
組的安全設置顯示了細節
通過任何一種管理器接口都能提供這種細節
在更深入地鑽研這些之前
注意一下圖
中命名為
DNSAdmins
的組
這是一個在活動目錄中預配置的組
通過使一個一般用戶成為這個組的一員
一個管理員可以授予這個用戶一個DNS管理員的許可
如你猜想的一樣
一個
DNSAdmins
成員有足夠的能力配置和運行在域控制器上永久駐留的所有DNS服務器上的DNS
但是沒有對其他特征的管理權
除非這些特征通過其他組獨立地被授予特權
因此
上一段說的是任何能和DNS協商一個安全對話作為認可陳述（授權用戶成員）的客戶機都可以創建資源記錄
當一個非安全的更新被協商
DNS服務器提供了一個更新的上下文
圖
顯示了對A記錄缺省創建的安全保障
表明了
Everyone
組被授權
Read（讀取）
許可
如果想再深入一點兒看的話
如圖
所示
可以找到相同的被授權的
Read
許可
但這種情況下是對一個資源記錄而言的
如以上所見
應該指出的一點是授權用戶可以在域區內創建對象
盡管這樣創建對象的類型會受到限制
但如何進行創建卻不受限制
如果用戶作為一個授權用戶使用直接的LDAP方法
仿佛就根本不用涉及到DNS服務器
換句話說
域中任何合法用戶都能創建記錄
甚至可以直接創建
為了改變創建記錄時對其授權的許可
對活動目錄容器和域區的可繼承許可可以改變
一般來說
實際的需求非常復雜
對原型或者說對被創建對象類型的對象類也有許可
當在其中創建新的記錄時這些許可也會被應用
不論是對域區還是資源記錄
在
out
of
the
box
設置中
模式類dnsZone和dnsNode對新創建的域區或資源記錄都會提供授權許可
圖
給出了用於資源記錄的dnsNode類的缺省安全描述符
dnsZone類是相似的
此外它也對授權用戶賦予許可去創建子對象
如果我們再深入地研究下去
在圖
中（對一個資源記錄）
我們會發現Everyone的讀取許可和圖
一模一樣
這是顯然的
因為圖
中的內容正是從圖
得來的
此許可不是從域區ACL繼承的
並且對域區的ACL的大多數改變都不會影響Everyone組對域區裡新的資記錄的讀取權利
那麼
迄今為止我們知道了些什麼？一個協議定義了進行動態DNS更新時DNS服務器使用的安全上下文
任何授權用戶都能創建新記錄
Everyone組的每個成員都能讀取一個記錄
也能列出一個域區
在記錄被創建以後
它只能被管理員或系統或創建此記錄的帳戶來改變
在包含的域區或dnsNode圖表對象中對許可的操作可能改變新創建的資源記錄的缺省許可
最後詳述一下
如何預先確定由動態DNS產生新記錄的安全ACL
任何沒有明確提供ACL的新的活動目錄對象被創建後
它就得到一個ACL
這個ACL包含著從它們的容器或從對象原型缺省的安全描述符繼承的安全許可
除非對它的容器至少有一項特別指定的許可
當有指定的許可出現在容器中時
原型的許可不被使用
因此
當創建新記錄時不禁止從原型得到許可
將得到dnsNode的許可加上記錄被創建的域區的任何可用的繼承許可
下面看一下禁止使用原型許可的指定許可
如果容器有任何指定給被創建對象類型的繼承許可
此類的原型的缺省安全描述符就不會被新對象接受
新對象只接受從容器得到的繼承許可
所以
如果域區有可繼承的許可並且已經應用於資資源記錄（dnsNode類的對象）
域區裡新的資源記錄就只會接受域區裡可繼承的許可
由微軟提供的目前的MSDN中的
活動目錄程序員指南
以文檔的方式指出了覆蓋一個活動目錄對象接受的它的類的缺省安全措施的方法
但是
因為在windows
的最初版本中
管理員接口中不提供關鍵性的先決條件
所以目前還不能禁止來自dnsNode和dnsZone的缺省安全措施
不向域區或資源記錄對象提供任何指定的許可
如果禁止原型安全措施成為可能
那麼不論你是在想使用許可還是在不想使用時避免使用許可
你都得清楚這一點
這裡有一個預防措施
在一個域區被創建之後
改變它的許可可以防止缺省的安全描述符（在dnsNode原型上的）被加到新的資源記錄上去
這也許被期望
也許不被期望
如果沒有應用原型缺省的安全措施
就必須保證包含域區中有可繼承的許可
以提供原型中缺省安全措施中被期望的部分（被禁止的）的
可以看到包含域區中的許可可控制新的被包含對象（資源記錄）的安全措施
這個控制必須很小心地完成
並且有兩個方面要考慮
包含域區的可繼承的許可和來自原型（dnsNode）的缺省許可
沒有提到的是
改變對dnsNode原型的安全措施是一個影響活動目錄中每個域的行為（例如
假如Everyone的讀取權太過頭了）
不僅僅是這樣做
還必須理解Everyone為什麼賦予這個許可以及為什麼在某種程度上它還很難被覆蓋
如果訪問能被破壞的事實能被接受的話
改變dnsNode的許可是完成像這樣的改變的最簡單的方法
但是任何架構層的改變都不能輕易地被改變
在一個域區被創建以後
加入能被創建任何子對象繼承的許可會改變域區裡將來會被創建的資源記錄的許可
因為dnsZone和dnsNode類規定Everyone組和授權用戶組分別有讀取域區數據和創建的許可
正如前所示
關於許可方面實在是沒什麼添加的了
所以
對原型安全措施的改變暗示著out
of
the
box設置不適合你的環境
這又意味著對架構類改變的許可
以及由原型或域區許可提供的期望部分的許可的完全理解
一些實驗能使這變得容易理解
如果微軟或者是通過擴展的第三方
使得一個合格的資源記錄的指定權限ACE能被應用於域區
那就什麼事也沒有了
從windows
的測試版到最終版
一直采用用禁止應用架構類的缺省安全描述的方法
然而
有了黃金代碼
似乎有些東西已經改變了但還沒有被規范成文檔
先前可選的一些對象類的例子現在已經不適用了
因為安全是一個大問題
而復雜性也不小
很有可能提供修訂信息和期望的方法
就像實施windows
的網絡環境一樣
需要從微軟得到如何改變域區數據安全性的改進信息
現在
在這些被印刷前的最後時刻
原型的缺省值需要被整理
改變原型的缺省值到最不公用的權限集和當需要多於最不公用的權限集時對域區添加可繼承的權限
是一個可利用的手段
對架構類的改變能夠通過活動目錄架構管理控制器（SCHMMGMT
MSC）來完成的
對域區的改變能夠通過活動目錄用戶和計算機控制管理（DSA
MSC）來實現
或者通過DNS服務器管理控制台（DNSMGTMSC）來實現
現在再看一下DNS數據安全的另一方面
審計
圖
給出了設置一個域區創建的記錄的缺省值以使它們是有審計功能
圖中的復選框指出了什麼行動會引發審計
它們顯示為灰色是因為這些設置是從更高層繼承的
當審計開始後
這些設置會引起除了對記錄的讀取外所有的訪問都會被寫入一個審計記錄
如果再回到圖
可以注意到對
Everyone
的讀取權限用白色框來顯示
這是因為源於dnsZone類的權限直接應用於資源記錄
這表明如果想要改變以這種方式賦予的權限
即沒有使用繼承
那最好是在所有對象被創建之前就改變控制設置
在對象存在以後
改變並且是只改變這些權限
就需要單獨地訪問每一個資源記錄對象
(未完待續)
From:http://tw.wingwit.com/Article/os/fwq/201311/10291.html
