為什麼TPAM會使用49154, 49155 port 連接受管目標主機?

49154 and 49155 是 Windows Server 內部定義的RPC dynamic port，當TPAM使用TCP/135和受管目標主機初始連接後，接下來會使用RPC dynamic port來做後續的連接。

WMI / DCOM from DPA/TPAM will need access to TCP/135 to initiate communication on the target. The subsequent conversation then continues on a random negotiated port.
On Windows 2003/XP this would be in the range 1025 - 5000 on Windows 7/Windows 2008 and above : 49152 - 65535.

TPAM的標準功能會使用WMI/DCOM access  target，沒有強制關閉的方式。

如果要避免TCP/135, 49154, 49155 的使用的話，

1. 請確認沒有使用下列功能

- Managing service account passwords ("Change password for Windows Service started by this account" ticked)
- Managing scheduled task passwords ("Change password for Scheduled Tasks started by this account" ticked)
- Restarting a service ("Automatically restart such Services" ticked)
- Using Account Discovery on the target
- Using Event Capture on PSM sessions (Privileged Session Manager)

2. 請確認每套windows server的 System->Deteils->Information-> 填寫Computer Name(用大寫英文字母)，如果沒有填寫TPAM會使用WMI連接目標主機獲取主機名稱。

參考資訊:
1. How to configure RPC dynamic port allocation to work with firewalls
2. https://support.oneidentity.com/kb/123021/ports-used-by-windows-or-windows-active-dir-platforms
3. https://support.oneidentity.com/tpam/kb/230930/which-tpam-features-use-wmi-and-which-do-not-

[One Identity Safeguard] PAM 解決方案

特權帳號 - 資安與系統管理員面臨的挑戰

平台多元，管理不易

• 即便是資深MIS，也很難同時管理不同平台的特權帳號

共用特權帳號，無法識別使用者

• 為了避免密碼遺失的風險，使用「預設」密碼
• 「千年帳號」無法回收

特權帳號擁有系統”完整的”控制權

• 高權限等於高風險，隨時監督難度高
• 僅能透過系統內部「預設」的控制權管理
• 無法管控系統層級的指令或程式

稽核資訊不完全

• 僅能追蹤系統內部的Log紀錄
• 文字型態紀錄不明確也不易理解

特權設備申請流程繁瑣

• 面臨各種不同平台的特權帳號管理，增加審核難度
• 人為審核，無效率也不易追蹤

人為變更密碼，增加工作量

• 避免遺失或忘記，可能使用紙本或電子檔來紀錄
• 密碼重複使用，容易被猜測
• 無法確保符合強密碼規則

One Identity Safeguard 的產品效益

1. 減輕安全漏洞可能造成的損害
2. 滿足法令遵循要求
3. 高效的稽核報告創建
4. 簡化特權帳戶管理 - 清楚明瞭對特權帳號和共用帳號的管理
5. 自動化密碼異動和客製化密碼規則
6. 增加對帳號/密碼的審核流程與審核能力
7. 有效監控和完整記錄特權帳號使用者行為

[Active Roles] How to, One Identity Active Roles - 如何彈性的調整 change workflow?

隨著企業的快速發展，AD管理員面臨一個問題: 他們需不眠不休的奮力支援業務需求及滿足稽核人員。每天面對成千上百的新增刪需求，加上授權控制權給不同的管理群組，異動前需要關鍵人員在流程中進行審核等等。

現在透過 One Identity Active Roles (ARS)，即可輕鬆有效的保護 AD 和 AAD，解決安全議題並符合法規需求，以ARS自動化工具，便彌補AD和AAD原生工具的不足。

基於定義的管理策略和相關權限，ARS提供全面的特權帳戶管理，使您能夠使用最小權限來委派控制權，也可以OU為單位，賦予使用者或群組的管理權限，有效提升IT人員的工作效率。

今天的透過委派管理權限的範例，來說明如何進行彈性的調整。

將PSD這個OU的帳號與群組管理權限，委由特定帳號sguser3，透過瀏覽器即可管理OU。

ARS內建workflow，當委派使用者或群組異動權限給特定帳號時，我們同時可以限定該異動必須先通過審核程序(主管，人資或是IT)，始能生效。同時也保留彈性。

建立資料異動的 change workflow

透過瀏覽器，sguser3修改了testuser1的電話號碼，但是必須先經過審核後才會異動。

依公司規範，定義必須的審核層級。

更進一步，我們可以設定白名單與黑名單。

1. 正向表列 – 限定當特定帳號或群組進行異動時，才需要審核流程。(使用 Initiator Condition)

正向表列

2. 負向表列 – 可以將特定名稱的帳戶跳過審核流程。(使用Filtering Condition)

排除清單

將sguser3設定為排除名單

將sguser3設定為排除名單

透過第二種負向表列的方式，我們將PSD OU的委派管理員sguser3，在workflow中設定為排除名單之後，再試著修改testuser1 的電話號碼，就不需要跑簽核流程了。

修改電話號碼

無須審核即可異動。