کارمند جدید در سیستم منابع انسانی ثبت شده است، اما هنوز تیم IT از ورود او خبر ندارد. چند ساعت بعد یک ایمیل یا فایل Excel برای ساخت حساب میرسد. کارشناس باید نام کاربری بسازد، واحد سازمانی را انتخاب کند، Groupها را اضافه کند، Mailbox و Microsoft 365 را تنظیم کند و مطمئن شود اطلاعات با HR یکی است. اگر عنوان شغلی یا واحد کارمند تغییر کند، دوباره همان مسیر دستی تکرار میشود. هنگام خروج نیز ممکن است بین ثبت خروج در HR و غیرفعال شدن حساب در Active Directory چند ساعت یا حتی چند روز فاصله بیفتد.
مشکل اصلی این سناریو «ساخت User» نیست؛ مشکل این است که منبع حقیقت منابع انسانی از سیستم هویت جداست. راهکار حرفهای، اتصال HRMS به AD360 و تبدیل رویدادهای HR به Provisioning و Deprovisioning کنترلشده در Active Directory، Microsoft 365 و سایر سرویسهای سازمانی است.
در معماری ManageEngine AD360، ماژول مدیریت Active Directory یعنی ADManager Plus قابلیتهایی مانند HRIS/HCM-driven provisioning، Automation Policy، Approval Workflow، Smart Template و Orchestration را فراهم میکند. هدف این مقاله طراحی همین مسیر است: چگونه HRMS را به هویت سازمانی متصل کنیم، چه دادههایی باید Map شوند، Approval کجا قرار بگیرد، چه زمانی Webhook لازم است و چطور از ساخت Account اشتباه یا دسترسی اضافی جلوگیری کنیم.
HR-driven Provisioning چیست؟
HR-driven Provisioning یعنی سیستم منابع انسانی یا HCM به Trigger اصلی چرخه عمر هویت تبدیل شود. وقتی HR یک Employee جدید ایجاد میکند، تغییر سمت یا واحد را ثبت میکند یا وضعیت استخدام را به Terminated تغییر میدهد، این Event میتواند فرآیند Identity Management را آغاز کند.
در مدل دستی، HR اطلاعات را برای IT ارسال میکند و IT دوباره همان داده را وارد میکند. در مدل HR-driven، داده از منبع اصلی خوانده و با Rule، Template و Workflow به Directory منتقل میشود.
| رویداد HR | عملیات Identity | نمونه خروجی |
|---|---|---|
| New Hire | Provisioning | AD User، Group، Mailbox، Microsoft 365 |
| Department Change | Modification | OU/Group/Attribute Update |
| Promotion | Access Change | Role-based Group Assignment |
| Location Change | Profile Update | Office، Site، Group یا Policy |
| Leave/Termination | Deprovisioning | Disable، Remove Group، Mailbox Action |
| Contract End | Scheduled Action | Disable در تاریخ مشخص |
AD360 در این معماری چه نقشی دارد؟
صفحه رسمی AD360، Identity Life Cycle Management را یکی از Capabilityهای اصلی این پلتفرم معرفی میکند. این لایه از قابلیتهای ماژول ADManager Plus برای مدیریت و اتوماسیون Active Directory و سرویسهای مرتبط استفاده میکند.
ManageEngine در AD360 چهار جزء کلیدی برای چرخه هویت معرفی میکند:
- Automation Policies: زنجیرهای از Taskهای مدیریتی را طبق Schedule یا Policy اجرا میکنند.
- Orchestration Templates: با Webhook، Custom Script و Logic Block عملیات را میان Directory و Applicationها هماهنگ میکنند.
- Smart Templates: Attributeها و Ruleهای ساخت یا تغییر User را استاندارد میکنند.
- Notification Templates: نتیجه عملیات را برای Admin یا Stakeholderهای مربوطه ارسال میکنند.
بنابراین اتصال HRMS فقط «خواندن Employee List» نیست؛ باید داده HR وارد یک Pipeline کنترلشده شود و سپس بر اساس Rule و Approval به Directory برسد.
چه HRMSهایی را میتوان به ADManager Plus متصل کرد؟
طبق مستند فعلی ManageEngine، ADManager Plus Integration آماده یا سناریوی HRIS-driven برای پلتفرمهایی مانند Zoho People، UKG Pro، BambooHR و Workday ارائه میدهد و همچنین میتواند با External Database یا Custom HCM که REST API مناسب دارد یکپارچه شود.
این نکته برای سازمانهای ایرانی مهم است؛ چون لزوماً HRMS آنها یکی از محصولات بینالمللی آماده نیست. اگر سامانه منابع انسانی داخلی REST API قابل اتکا ارائه دهد، Custom HCM Integration میتواند گزینه مناسبتری باشد.
معماری پیشنهادی اتصال HRMS به AD360
یک معماری ساده و قابل کنترل میتواند این مسیر را داشته باشد:
HRMS/HCM → API یا Prebuilt Integration → ADManager Plus → Mapping/Template → Approval → Automation/Orchestration → AD / Microsoft 365 / Apps → Audit & Notification
هر لایه وظیفه مشخصی دارد. اگر Mapping و Approval حذف شوند، Automation میتواند خطا را سریعتر منتشر کند.
لایه ۱: HRMS بهعنوان Source of Truth
نام، نام خانوادگی، Employee ID، Department، Manager، Location، Job Title، Start Date، Last Working Day و Employment Status بهتر است از سیستم HR خوانده شوند، نه اینکه IT دوباره آنها را تایپ کند.
لایه ۲: Integration
اتصال میتواند از Integration آماده، API یا Custom HCM انجام شود. در مستند Custom HCM ManageEngine، Endpoint باید Employee Data را در قالب JSON ارائه کند و روشهای احراز هویت پشتیبانیشده شامل Basic Auth، OAuth 2.0 با Authorization Code، Bearer و API Key هستند.
لایه ۳: Mapping
فیلد HR باید به Attribute درست در Directory متصل شود. برای نمونه:
| HRMS Field | AD/Identity Field | نکته |
|---|---|---|
| Employee Number | employeeID | بهتر است Immutable و Unique باشد |
| First Name | givenName | Unicode و Data Quality کنترل شود |
| Last Name | sn | برای Naming Policy استفاده میشود |
| Department | department | مبنای Group/OU میتواند باشد |
| Manager ID | manager | نیازمند Resolve به DN یا Identity صحیح |
| Job Title | title | برای Role Mapping کاربرد دارد |
| Office | physicalDeliveryOfficeName | برای Site-specific Policy مفید است |
| End Date | Automation Trigger | نباید فقط بهعنوان Text ذخیره شود |
Employee ID را کلید اصلی طراحی کنید، نه نام و نام خانوادگی
نام افراد Unique نیست، ممکن است تغییر کند و در فارسی/انگلیسی چند شکل نوشتاری داشته باشد. برای Correlation میان HRMS و AD بهتر است یک Identifier پایدار مانند Employee ID مبنا باشد.
اگر دو «علی رضایی» وارد سازمان شوند، Rule مبتنی بر Display Name میتواند حساب اشتباه را Modify کند. Identifier پایدار باید در Mapping و Reconciliation مرکز طراحی باشد.
Smart Template چگونه خطای ساخت User را کم میکند؟
Smart Template اجازه میدهد Attribute و Rule بر اساس Department، Role یا سایر Criteria از قبل تعریف شوند. برای مثال کارمند واحد مالی میتواند Template متفاوتی از کارمند فنی داشته باشد.
بهجای اینکه هر بار کارشناس این موارد را انتخاب کند:
- OU؛
- Username Format؛
- UPN Domain؛
- Group Membership؛
- Mailbox Setting؛
- Microsoft 365 Assignment؛
- Home Folder؛
Template میتواند مقدارها را بر اساس Rule از پیش تعیین کند.
Naming Policy را قبل از Automation نهایی کنید
یکی از بدترین زمانها برای حل Naming Convention، بعد از شروع Auto-Provisioning است. قبل از اتصال HRMS باید قواعد sAMAccountName، UPN و Email مشخص شوند.
نمونهها:
firstname.lastnamef.lastnameemployeeID- ترکیب Name + Employee ID برای جلوگیری از Duplicate
Rule باید Collision Handling هم داشته باشد. اگر Username از قبل وجود داشت، سیستم نباید بدون کنترل حساب موجود را تغییر دهد.
Provisioning بدون Approval یا با Approval؟
پاسخ برای همه Taskها یکسان نیست. ایجاد User معمولی میتواند کاملاً خودکار باشد، اما عضویت در Groupهای حساس، Privileged Role یا Access خاص بهتر است Approval داشته باشد.
| عملیات | پیشنهاد |
|---|---|
| ایجاد User استاندارد | Automation پس از Data Validation |
| Assign گروه عمومی Department | Automation |
| Privileged Group Membership | Approval الزامی |
| Mailbox/M365 پایه | طبق Policy سازمان |
| Financial/Admin Access | Multi-level Approval |
| Disable در تاریخ خروج | Scheduled/Event-driven Automation |
ManageEngine در ADManager Plus Approval-based Workflow را برای کنترل عملیات حساس ارائه میدهد. هدف Automation حذف Governance نیست؛ هدف حذف کار تکراری همراه با حفظ کنترل است.
HR Event باید چه زمانی وارد AD شود؟
همه دادههای HR نباید بلافاصله Provision شوند. Start Date، Status و Approval باید در Trigger Logic لحاظ شوند.
برای New Hire ممکن است بهترین Rule این باشد:
- Employee در HR ایجاد میشود.
- Offer/Employment Status به Active میرسد.
- Start Date وارد بازه مجاز میشود.
- Manager یا HR Approval کامل میشود.
- Automation User را ایجاد میکند.
این طراحی جلوی ساخت حساب برای Candidate، Draft Employee یا استخدام لغوشده را میگیرد.
Mover؛ بخش فراموششده چرخه هویت
بیشتر سازمانها برای Joiner و Leaver Workflow دارند، اما تغییر سمت یا Department را دستی رها میکنند. نتیجه Privilege Creep است: کاربر وارد واحد جدید میشود اما Groupهای قدیمی را هم نگه میدارد.
در HR-driven model، تغییر Department میتواند Trigger برای:
- Update Attribute؛
- جابجایی OU؛
- افزودن Groupهای Role جدید؛
- حذف Groupهای Role قبلی؛
- تغییر License یا Mailbox Policy؛
- ارسال Task برای Access Review؛
باشد.
برای کنترل دسترسیهای انباشته، مقاله Access Certification در ADManager Plus مکمل مستقیم همین سناریو است.
Offboarding را فقط Delete User تعریف نکنید
Deprovisioning حرفهای معمولاً چند مرحله دارد. مستند رسمی ADManager Plus برای User Deprovisioning به عملیاتهایی مانند Disable Account، Revoke Group Membership، Remove Mailbox Access و انتقال حساب به OU مشخص اشاره میکند.
بسته به Policy سازمان، مسیر میتواند چنین باشد:
- در Last Working Day حساب Disable شود.
- Session و Accessهای لازم Revoked شوند.
- Group Membershipهای غیرضروری حذف شوند.
- Mailbox و Microsoft 365 طبق Retention Policy مدیریت شوند.
- Manager یا Successor برای Data Ownership تعیین شود.
- پس از Retention Period، Delete نهایی انجام شود.
اگر هدف شما راهنمای عمومی Onboarding/Offboarding است، مقاله Onboarding و Offboarding کاربران با ADManager Plus موضوع را از زاویه پایه پوشش میدهد. مقاله حاضر عمداً روی Integration و HR-driven Automation متمرکز است.
Orchestration چه زمانی لازم میشود؟
اگر فقط Active Directory را مدیریت کنید، Automation داخلی کافی است. اما Employee Lifecycle معمولاً از AD فراتر میرود: CRM، ERP، SaaS، Service Desk، Asset Management و ابزارهای دیگر.
ADManager Plus Orchestration Template میتواند Webhook، Custom Script و Logic را وارد Workflow کند. ManageEngine حتی نمونه Offboarding را مستند کرده که با Webhook برای حذف حساب از Applicationها و Reclaim کردن Asset از ServiceDesk Plus Cloud استفاده میشود.
این یعنی معماری JML میتواند از «Directory Automation» به «Cross-Application Identity Orchestration» برسد.
Webhook یا API؛ کدام برای HR Integration مناسبتر است؟
اگر HRMS API ارائه میدهد، معمولاً Pull/Sync یا Event-driven Integration ممکن است. اگر HRMS Webhook خروجی دارد، میتوان Trigger سریعتری طراحی کرد. انتخاب به Capability دو طرف بستگی دارد.
| روش | مزیت | ریسک/ملاحظه |
|---|---|---|
| Scheduled API Pull | ساده و قابل کنترل | Delay بین دو Sync |
| Inbound Webhook | Near Real-time | Authentication و Replay Protection مهم است |
| Database Integration | مناسب سیستمهای قدیمی | Coupling بیشتر و نیاز به کنترل Schema |
| CSV Import | مناسب Bulk Migration | برای Lifecycle روزمره ایدهآل نیست |
امنیت API اتصال HRMS
HRMS داده بسیار حساس دارد؛ بنابراین Integration Credential نباید مانند یک Script ساده مدیریت شود.
حداقل کنترلها:
- Dedicated Service Account؛
- Least Privilege Scope؛
- TLS معتبر؛
- OAuth 2.0 در صورت امکان؛
- Rotation برای API Key/Secret؛
- IP Restriction در صورت پشتیبانی؛
- Audit Log برای درخواستها؛
- عدم ثبت Secret در Log؛
- Timeout و Retry کنترلشده؛
- Rate Limit و Failure Handling.
Data Quality قبل از Automation
اگر HRMS دارای Departmentهای تکراری، Manager خالی، Employee ID نامعتبر یا Locationهای ناسازگار باشد، Automation این خطاها را به AD منتقل میکند.
قبل از Go-live این Quality Gateها را بسازید:
- Employee ID اجباری و Unique؛
- Department از Controlled List؛
- Manager قابل Resolve؛
- Start/End Date معتبر؛
- Email/Naming Character Validation؛
- Employment Status استاندارد؛
- Location و Legal Entity مشخص.
Reconciliation؛ اگر HR و AD با هم اختلاف داشتند چه کنیم؟
Integration واقعی همیشه Exception دارد. ممکن است User دستی ساخته شده باشد، Employee ID تغییر کرده باشد یا یک Account Service با کارمند اشتباه Match شود.
Rule خطرناک این است که «HR همیشه بدون بررسی روی AD overwrite کند». بهتر است اختلافها Classify شوند:
- Safe Auto-fix؛
- Needs Approval؛
- Needs Manual Review؛
- Protected Account — Never Auto-change.
حسابهای Domain Admin، Service Account و Break-glass باید از Automation عمومی جدا باشند.
Scenario: HRMS ایرانی با REST API
فرض کنید سازمان از یک HRMS داخلی استفاده میکند و Vendor API زیر را ارائه میدهد:
GET /api/employees?updated_since=...
خروجی شامل Employee ID، Name، Department، Manager، Job Title، Start Date و Status است.
طراحی پیشنهادی:
- Custom HCM Integration در ADManager Plus تعریف شود.
- Authentication API تنظیم شود.
- Endpoint و JSON Mapping ساخته شود.
- Employee ID به Attribute پایدار Map شود.
- Smart Template بر اساس Department تعریف شود.
- Automation فقط Employeeهای Active را Provision کند.
- Group حساس وارد Approval Workflow شود.
- Termination Date به Deprovisioning Policy متصل شود.
- Failure Notification به Identity Admin ارسال شود.
در این مدل، مدانت میتواند بخش Custom API Mapping و Integration را متناسب با HRMS سازمان طراحی کند.
Scenario: تغییر واحد کارمند
HR واحد کارمند را از Sales به Finance تغییر میدهد. این Event نباید فقط فیلد Department را عوض کند.
Rule بهتر:
- Department Update تأیید شود.
- OU یا Attribute لازم تغییر کند.
- گروههای پایه Sales حذف شوند.
- گروههای پایه Finance اضافه شوند.
- گروههای Sensitive نیازمند Approval باشند.
- Access Certification برای دسترسیهای خارج از Role فعال شود.
این دقیقاً نقطهای است که Identity Lifecycle از «ساخت User» به Governance تبدیل میشود.
Scenario: خروج فوری کارمند
در بعضی Terminationها نمیتوان تا Sync شبانه صبر کرد. HR Status باید Trigger فوری ایجاد کند.
برای چنین مواردی، یک Emergency Offboarding Path تعریف کنید که:
- Account را Disable کند؛
- High-risk Groupها را Remove کند؛
- Notification به Security و Manager بدهد؛
- Taskهای Post-offboarding را Orchestrate کند.
اما Delete نهایی میتواند طبق Retention Policy زمانبندی شود.
HRMS Integration و ServiceDesk Plus چگونه مکمل هم هستند؟
HRMS منبع Employee Event است، AD360 هویت و دسترسی را مدیریت میکند و ServiceDesk Plus میتواند Taskهای عملیاتی Onboarding مثل تحویل Asset، نصب نرمافزار و درخواستهای Department را مدیریت کند.
برای نگاه ITSM به این فرآیند، مقاله Onboarding و Offboarding در Service Management مفید است.
در معماری پیشرفته، Identity Event میتواند با Workflowهای ITSM و Asset Reclamation همگام شود. اگر Integration سفارشی لازم باشد، مقاله Webhook و API در ServiceDesk Plus الگوی طراحی Integration امن را توضیح میدهد.
AD360 یا فقط ADManager Plus؟
اگر مسئله اصلی شما فقط Active Directory Administration، User Provisioning، Workflow و Reporting است، ADManager Plus هسته اصلی این Use Case است. AD360 زمانی ارزش بیشتری پیدا میکند که سازمان بخواهد Identity Management را با Self-Service/MFA، Auditing، Risk/ISPM و سایر قابلیتهای Identity Security در یک معماری یکپارچه ببیند.
صفحه ADManager Plus مدانت برای Capabilityهای تخصصی مدیریت AD است و صفحه AD360 مدانت Pillar اصلی Identity Platform را پوشش میدهد.
این مقاله با ISPM در AD360 چه تفاوتی دارد؟
مقاله ISPM در AD360 درباره Risk Score، Attack Path و کاهش ریسک Identity است. این مقاله درباره ورود داده HR و اجرای Lifecycle Automation است.
این دو مکملاند: یکی Identity را درست Provision میکند و دیگری Exposure و Risk آن را ارزیابی میکند.
KPIهای مناسب HR-driven Provisioning
| KPI | تعریف |
|---|---|
| Time to Provision | از Ready شدن Employee در HR تا آماده شدن Identity |
| Provisioning Success Rate | درصد اجرای بدون خطا |
| Manual Touch Rate | درصد Userهایی که نیاز به دخالت دستی دارند |
| Attribute Error Rate | درصد اختلاف HR و Directory |
| Time to Deprovision | از Termination Event تا Disable Access |
| Privilege Carryover Rate | دسترسیهای Role قبلی پس از Move |
| Approval SLA | زمان انتظار عملیات حساس برای Approval |
یک Pilot کمریسک چگونه اجرا شود؟
- یک Department با ۲۰ تا ۵۰ User انتخاب کنید.
- فقط ۱۰ تا ۱۵ Attribute ضروری را Map کنید.
- Provisioning اولیه را بدون Privileged Group اجرا کنید.
- Naming Collision را تست کنید.
- Manager Resolve را تست کنید.
- یک Mover Scenario اجرا کنید.
- یک Future Termination را در محیط Test اجرا کنید.
- API Failure و Timeout را شبیهسازی کنید.
- Approval Workflow را Verify کنید.
- Audit و Notification را بررسی کنید.
اشتباههای رایج در اتصال HRMS به AD360
- استفاده از Name بهجای Employee ID برای Correlation؛
- Automation روی Data Quality ضعیف؛
- اعطای Privileged Access بدون Approval؛
- نداشتن Exclusion برای Service Account و Admin Account؛
- Delete فوری بدون Retention Policy؛
- نادیده گرفتن Mover و تمرکز فقط روی Joiner/Leaver؛
- نگهداری API Secret داخل Script یا فایل Plain Text؛
- نداشتن Retry و Failure Queue؛
- نداشتن Audit Trail برای تغییرات خودکار؛
- Go-live سراسری بدون Pilot.
چکلیست طراحی Integration
- HRMS بهعنوان Source of Truth مشخص شده است.
- Employee ID Unique و پایدار است.
- API Authentication امن است.
- Attribute Mapping مستند است.
- Naming Policy و Collision Rule تعریف شده است.
- Smart Template بر اساس Role/Department وجود دارد.
- Privileged Groupها Approval دارند.
- Start Date و End Date در Trigger Logic استفاده میشوند.
- Mover Scenario طراحی شده است.
- Protected Accountها Exclude شدهاند.
- Failure Notification تعریف شده است.
- Audit Log نگهداری میشود.
- Offboarding با Retention Policy هماهنگ است.
- ITSM و Asset Workflow در صورت نیاز Orchestrate شدهاند.
نکات کلیدی
- هدف اتصال HRMS به AD360 حذف ورود دوباره داده و کوتاه کردن فاصله HR Event تا Identity Action است.
- ADManager Plus در معماری AD360 قابلیت HRIS-driven provisioning، Automation، Workflow و Orchestration را فراهم میکند.
- Workday، BambooHR، UKG Pro و Zoho People از نمونه HR Platformهای ذکرشده در مستند ManageEngine هستند و Custom HCM نیز با API قابل اتصال است.
- Employee ID باید کلید Correlation باشد؛ Name کلید مطمئنی نیست.
- Mover بهاندازه Joiner و Leaver مهم است، چون Privilege Creep معمولاً هنگام تغییر Role ایجاد میشود.
- Automation نباید Governance را حذف کند؛ عملیات حساس باید Approval داشته باشند.
- Custom Integration برای HRMSهای داخلی میتواند مسیر مستقیم درآمدی برای طراحی و پیادهسازی تخصصی مدانت باشد.
منابع
- ManageEngine — AD360 Identity Life Cycle Management Features
- ManageEngine — ADManager Plus Active Directory Automation
- ManageEngine — Identity Orchestration
- ManageEngine — Integrating HCM Applications with ADManager Plus
- ManageEngine — Automating Joiner, Mover and Leaver Life Cycle Management
سخن پایانی
اتصال HRMS به AD360 زمانی ارزش واقعی دارد که HR Event مستقیماً به یک Identity Workflow قابل کنترل تبدیل شود. هدف فقط سریعتر ساختن User نیست؛ هدف این است که Attribute درست، Access درست و زمانبندی درست بدون ورود دوباره داده اجرا شوند و هر تغییر Audit Trail مشخص داشته باشد.
در این معماری، HR منبع حقیقت Employee Data است، ADManager Plus در AD360 Lifecycle Automation را اجرا میکند و Approval و Orchestration اجازه میدهند عملیات حساس یا Cross-Application تحت کنترل باقی بمانند.
مدانت میتواند در استعلام و خرید لایسنس AD360 و ADManager Plus، اتصال HRMSهای داخلی و خارجی، طراحی Custom HCM/API Integration، Mapping داده، Automation Policy، Approval Workflow، Orchestration، مهاجرت، استقرار و پشتیبانی همراه سازمان باشد. برای بررسی سناریوی HRMS خود از تماس با مدانت یا درخواست جلسه فنی و دمو استفاده کنید.
