S小魚仔S IIS 7 安全性 認證 筆記

新增「IIS」遇到「認證」時，總是會有許多「困惑」，這回我還是做做筆記吧，相信使用「Windows」系統，架設「IIS」遇到「安全性」功能時，裡面都有這三樣「Windows 驗證」、「基本驗證」、「摘要式驗證」。

PS.

當您新增「IIS」預設會啟用「匿名驗證」

到底這四種「認證關係」有什麼樣的差別呢?

 我知道各位一定很好奇，因為我也很好奇，好奇之前，要花時間將下面看完。

「匿名驗證」

若「網站」啟用「匿名驗證」方法，則任何使用者都可以直接利用「匿名」來連接「網站」，不需要輸入「帳戶」與「密碼」，「Windows Server 2008 R2」 內建一個名稱為「IUSR」的「特殊群組帳戶」，當使用「匿名驗證」連接「網站」同時，網站則是使用「IUSR」，來代表這個「使用者」，因為使用者的「權限」就是與「IUSR」權限相同。

「基本驗證」

「基本驗證」會要求「使用者」輸入「使用名稱」與「密碼」，絕大部份瀏覽器都支援此「方法」，但是「傳送給」「網站」的「使用者名稱」與「密碼」並沒有被「加密」，因此容易被居心不良者「攔截」資料，故若要使用「基本驗證」的話，應該要搭配「SSL」( Secure Sockets Layer ) 連線。

「Windows 驗證」

「Windows」驗證，也會要求，輸入「使用名稱」與「密碼」，而且「使用者名稱」與「密碼」在透過「網路傳送前」，也會經過「雜湊」處理 (hashed)，因此可以確保「安全性」。

Windows 驗證 支援以下「兩種」驗證通訊協定:

「Kerberos v5」 驗證

如果「IIS」電腦是「Active Directory」網域成員，而且用戶端也支援「Kerberos v5」驗證的話，則「IIS」網站會採用「Kerberos v5」驗證方法。一般來說，「 Kerberos」 會被防火牆阻擋。

「NTLM」驗證

如果「IIS」電腦不是「Active Directory」網域成員 或 用戶端不支援「Kerberos v5」驗證的話，則「IIS」網站，會採用「NTLM」驗證方法。一般來說，代理伺服器 ( Proxy Server ) 不支援「NTLM」。

由於「Kerberos」會被「防火牆」阻擋且「代理伺服器」不支援「NTLM」，因此「Windows 驗證」，比較適合用來「連接內部」網路。用戶端利用「Windows 驗證」，來連接「內部」網站時，會自動利用「目前」的「使用者」與「密碼」，連接「網站」，因此若「使用者」沒有「權利」連接網站的話，就會要求「使用者」自行另外輸入「使用者名稱」與「密碼」。

「摘要式驗證」

「摘要式驗證」也會要求使「帳戶」與「密碼」，不過它比「基本驗證」更為安全，因為「使用者」的「帳戶」與「密碼」會經過「MD5」演算來處理，然後將處理後所產生的「雜湊」值 ( hash ) 傳送到網站。攔截此「雜湊」值得人，並無法從「雜湊」值得知「帳戶」與「密碼」。

必須具備以下條件，才可以使用「摘要式驗證」

* 瀏覽器必須支援 「HTTP 1.1」，例如 Internet Explorer 5.0 (含) 以上的版本。

* IIS 電腦必須是 「Active Directory」 網域的「成員伺服器」或「網站控制站」

* 使用帳戶必須是「Active Directory」網域使用者，而且此帳戶必須與「IIS」電腦位於同一個「網域」，或是「信任」的「網域」

各種驗證方法的比較

驗證方法	安全等級	如何傳送密碼	是否可通過防火牆或代理伺服器	用戶端的要求
匿名驗證	無		是	任何瀏覽器皆可
基本驗證	低	明文 (未加密)	是	大部分的瀏覽器
摘要式驗證	中	雜湊處理	是	Internet Explorer5 (含)以上
Windows驗證	高	Kerberos: Kerberos  ticket NTLM: 雜湊處理	Kerberos: 可通過代理伺服器，但會被防火牆阻擋 NTLM: 可通過防火牆，但是無法通過代理伺服器	Kerber: Windows 2000以後的系統，且使用Internet Explorer5 (含)以上 NTLM: Internet Explorer 2.0(含)以上

靜思:  世上有兩件事不能等「孝順」與「行善」。

參考資料:

「戴有煒」-「Windows Server 2008 R2 網路管理與架站」

S小魚仔S IIS 7 設定 SSL 憑證 攻略

使用「IIS」「憑證設定」之前，需要「新增」下列「服務」

「新增」=>「World Wide Web 服務」=>「 安全性」=>「IIS 用戶端憑證對應驗證」

開啟「IIS」設定「伺服器憑證」

點選「建立自我簽署憑證」
PS. 
「IIS」 可以自行產生「憑證」，但是此「憑證」，並非「公信單位」授權。

輸入「憑證」的「檔案名稱」

「設定」完成後，「伺服器」憑證，就會「自動」產生

「選擇」=>「網站」=>「繫結」

點選「新增」

1. 選擇「https」類型
2. 「SSL 憑證」，選擇「BookStory」
PS. 
剛剛 建立 的「憑證」

確認「Windows 防火牆」，有沒有開啟「HTTPS」通訊埠 ( 443 )

若您不放心，可以使用「命令提示字元」輸入「netstat -an」，檢查「通訊埠」有沒有「開放」「443」

開啟「瀏覽器」輸入「Https://IP」或「Https://domain」，會出現「以下提示」
PS. 
這是因為「憑證」的「來源」並非「公信單位」申請，而是透過「IIS」「自行建立」，所以會出現此訊息，點選「扔要繼續」

透過「Google Chrome」可以發現「憑證」顯示「X」

點開來觀察一下「發現」網站「身分未經驗證」，但是具有 TLS 1.0「加密」功能

點選「憑證資訊」

透過「複製到檔案」可以將「憑證」( .cer )，進行「匯出」

點選「下一步」

選擇「憑證」匯出「格式」，採用「預設值」

選擇「匯出路徑」

匯出「憑證」完成

接著「打開」，匯出「憑證」( .cer ) ，檢查一下發現「此訊息」，不會有任何「影響」
PS.
因為「憑證」的「來源」並非「公信單位」申請，而是透過「IIS」「自行建立」，所以會出現此訊息。

我應該如何，設定「公信單位」申請的「憑證」，請看「參考資料」，內有「保哥 (Will) 」完整設定。

靜思語:  時時好心，就是時時好日。

參考資料:

「Microsoft Technet」-「購買與安裝 SSL 憑證完全攻略 (以 IIS 7.0 為例)」

S小魚仔S Exchange Server 2010 SP2 簡易架設實戰

說到這玩意，真是「一波三折」，「話那要講透天」、「眼淚就飛不離」...誤，架設「Exchange Server 2010 SP2」，其實可以很省錢的，首先透過下方的「環境建置圖」，然後慢慢「告訴各位」

完成上述「步驟」，您還需要申請「No-IP」，這樣才可以將「Public」的「Domain」對應 到「Public」的「IP」，在網路世界裡，基礎就是「IP」，也就是您在「網路上」「唯一」的「門牌號碼」。

1. 設定「組織組態」=>「集線傳輸」=>「傳送連接器」
PS. 讓「內部」可以寄信到「外部」

名稱「自行定義」
傳送連接器用途「網際網路」

點選「新增」

位址空間「*」
PS.
使用「*」讓寄信可以出去到任意「Domain」

設定完畢以後，點選「下一步」

此時要選擇「MX」郵件主機，這裡選擇「使用網域名稱系統 (DNS) MX 紀錄以自動傳送郵件」

選擇「來源伺服器」，採用預設值

上述步驟，設定完畢以後，點選「新增」

此時，就可以在「傳送連接器」找到「設定」完成，的「名稱」

2. 設定「組織組態」=>「集線傳輸」=>「公認的網域」

PS. 使用這組「網域」( cmail.no-ip.org ) 對應到「Exchange」

輸入「NO-IP」註冊「Domain」
PS.
需要選擇「授權網域」

設定完成，就會出現「新增」完成的「公認網域」
PS
「demo.com」為「Windows AD」網域「產生」出來

3. 設定「組織組態」=>「集線傳輸」=>「電子郵件地址原則」
PS. 設定 「電子郵件」的「地址原則」修改「SMTP」之「位址」

點選「編輯」

輸入「指定郵件地址」，本範例使用「NO-IP」註冊「Domain」

4. 確認「使用者」的「電子郵件地址」
PS. 確認「使用者」的「帳戶」對應到「xxx@cmail.no-ip.org」

5. 登入「OWA」進行「外寄」測試


安裝「Exchange」會同時安裝「IIS」，開啟「IIS」會找到「OWA」服務

登入「OWA」透過「網頁」進行「寄件測試」

還有一樣非常重要需要「提醒」，因為「Exchange」架設在「防火牆」內，需要開啟下列「通訊埠」。
PS. 如果您丟在「DNZ」即不需「設定」下列「規則」

如果收到「Gmail」退信如下「訊息」
PS. 請勿採用「PPOE」撥接，因為屬於「浮動」的「IP」，請自行詢問「ISP」業者，申請「固定」的「IP」。

如果收到「下列訊息」，請設定「集線傳輸」=>「EXCHANGE」=>「Default Exchange」=>「權限群組」=>「匿名使用者」需要「打勾」

如果收到「下列訊息」，請重新開機「Exchange」
PS. 「多辦」都是「Exchange」服務，發生「問題」，請重新開機「Exchange」即可。

靜思語: 人間壽命因為短暫才顯得珍貴。 難得來一趟人間，應問是否有為人生發揮自己的功能，而不要一味求長壽。

PS. 

知識分享其實有「限」，有些屬於「內隱知識」，有些屬於「外隱知識」，都是需要透過「理解」和「消化」得到「正解」，總之「您花多少功夫」就會得到「多少回報」。

S小魚仔S Exchange Server 2010 五大角色

最近在學習安裝「Exchange」，不過老是搞不懂，幾合幾的「安裝方法」，紀錄下「基礎」的「Exchange」五大角色，( MBX、CAS、HT、Edge、UM )

信箱伺服器角色 ( MailBox Server Role ; MBX )

這個角色主要目的，在於負責「信箱」及「公用資料」的「資料庫」運作，產生「離線通訊錄」資料，以及「郵件位址」原則，與「郵件通訊錄」的運算。「Exchange」 以 「ESE」 作為資料庫運作基礎來處理「郵件」寫入 資料庫的程序，提供高效能的「資料庫處理」。

「MBX」 在部屬時需有以下 客觀條件:

必須加入 「AD DS 網域」

必要存在的「伺服器角色」

用戶端存取伺服器 ( Client Access Server Role ; CAS )

顧名思義，即是提供「用戶端」連線要求的「專屬」伺服器角色，這個角色的「功能」變化較大，在「Exchange Server 2007 」上，「CAS」 只提供給予「POP3/IMP4」、「OWA」、「Outlook Anywhere」、「Exchange Active Sync ( EAS )」等屬於「Non-MAPI」用戶端連線要求 ;

而屬於「MAPI」用戶端的「Outlook」則是以「RPC」協定，直接針對「MBX」提出連線要求。

在 「Exchange Server 2010」，「CAS」 除了依舊提供「None-MAPI」用戶端連線要求之外，其「MAPI」用戶端則利用「MAPI on The Middle Tier ( MoMT )」 技術，改為和「None-MPI」用戶端一樣是由「CAS」來回應連線要求。簡而言之，在「Exchange Server 2010」，所有用戶端類型全部由「CAS」提供集中連線要求。

「CAS」以「Web Service」為基礎的「Available Service」提供用戶端的「行事曆空間/忙碌」( Schedule Free/Busy ) 資訊的存取窗口，此外，「Autodiscovery」 及 「離線通訊錄」( Offline Address Book ; OAB ) 的 服務，也仍由 CAS 角色服務器提供 用戶端存取點。

「CAS」 在部屬時需有以下 客觀條件:

必須加入 「AD DS 網域」

必要存在的「伺服器角色」

集線器傳輸伺服器 ( Hub Transport Server Role ; HT )

主要提供所有「Exchange」組織內部的「郵件傳輸」服務，「電子郵件傳輸」規則套用、郵件「日誌」套用，並負責遞送「郵件訊息」到「使用者信箱」。

HT 負責在「Exchange」組織內，不同的「MBX」之間的「內部郵件遞送」，稱之為「訊息路由」( Exchange Route ) 。若「Exchange」組織，未規劃部署「邊際傳輸」伺服器角色，您也可以利用「HT」以「傳送連接器」及「接收連接器」為「運作基礎」，做為「直接轉寄」及「接收」 Internet 郵件 的「SMTP」伺服器，或以指定 HT 使用 智慧主機 ( Smart Host ) 方式 傳遞 Internet 郵件。此外，亦可在「HT」角色上安裝並設定「傳輸邊際」伺服器代理元件，已啟用「垃圾郵件」過濾等「相關功能」。

「HT」 在部屬時需有以下 客觀條件:

必須加入 「AD DS 網域」

必要存在的「伺服器角色」

邊際傳輸伺服器 ( Edge Transport Server Role ; Edge )

「Edge」 特別是以最小的網路被攻擊面而設計，目地為提供部署於非軍事區 ( Demilitarized Zone ; DMZ。微軟 將 DMZ 稱為 Permeter Network 或 Screen Subnet ) 專用 。其功能與「HT」相仿，也使用「傳送」及「接收連接器」為運作「基礎」，以「SMTP」郵件傳輸服務協定，或指定「智慧」主機方式，負責所有對「Internet」上的郵件「接收及傳遞」，而此時「Exchange」組織內部對外「Internet」郵件傳遞流程，即會由「原」負責遞送「Internet」郵件的「HT」角色，改為由「防火牆內部的 HT 角色」，將「郵件轉送」 ( Relay ) 至 DNZ 上的「Edge」角色，來完成「Internet」郵件遞送。

「Edge」本身也擁有一系列的代理元件 ( Agent ) ，以提供電子郵件傳輸規則套用、防堵垃圾郵件功能，以及提供防毒軟體外掛的角色對象。

 「Edge」因為被設計為提供「DNZ」專區部署專用，基於安全考量，「Edge」本身必須與「AD DS」服務採完全隔離方式的「獨立伺服器」( Stand-Alone Server ) 安裝。但如上述所說，「Edge」也提供「傳輸規則」套用，這需要配合 「AD DS」 上的「收件者清單」及相關設定資訊才能完成，而「清單」及「資訊的給予」，則需由「HT」與「Edge」間完成訂閱程序 ( Edge Subscription )後，透過由「HT」到「Edge」單向預設排成的「同步機制」( Edge Sync )，複製，並儲存於已安裝 AD LDS 服務 的  Edge 角色上。

「Edge」 在部屬時需有以下 客觀條件:

不可以加入 「AD DS 」網域，必須為獨立「伺服器」角色。

在「Exchange」組織內，非必要存在 ( 選項的 ) 伺服器角色。
需要安裝「AD LDS」服務

統一訊息伺服器角色 ( Unified Messagin Server Role ; UM )

UM負責將郵件與語音合併於使用者信箱當中，並提供以「電腦」或「電話」方式存取

以下為此角色在部署時的「客觀」條件 :
需加入「AD DS」網域。
放置於「防火牆」內部。
需要「MBX」和「HT」已安裝完成之環境。
部署時應盡可能接近「MBX」。
若考量企業分點地理位置，「UM」建議安裝於「總公司」內部「網路中」。


微軟官方網站 對「Exchange Server 2010」建議五個角色安裝前後順序為「CAS -> HT -> MBX -> Edge -> UM」

~~~~~~ Exchange Server 2010 角色部署及運作架構 ~~~~~~

典型 Exchange Server 部署

中型企業環境

小型企業環境

參考資料:

「Exchange Server 2010 SP1 實戰精粹」