Endpoint Central
یک سناریوی کاملاً رایج را در نظر بگیرید: قرار است ManageEngine Endpoint Central را برای مدیریت سیستم‌های سازمان نصب کنید. بیشتر کلاینت‌ها عضو Active Directory هستند، اما تیم امنیت می‌پرسد: «آیا خود سروری که Endpoint Central روی آن نصب می‌شود هم باید عضو Domain باشد؟»
پاسخ کوتاه این است: خیر؛ عضو Domain بودن خود سرور Endpoint Central الزام محصول نیست. Endpoint Central می‌تواند روی یک Windows Server مستقل یا عضو Workgroup نصب شود و در عین حال سیستم‌های عضو Active Directory، سیستم‌های Workgroup، چند Domain مختلف و حتی دستگاه‌های شعب یا کاربران راه دور را مدیریت کند.
نکته کلیدی:
«عضو Domain بودن سرور Endpoint Central» با «اضافه کردن Domain به Endpoint Central» دو موضوع کاملاً متفاوت است. برای مدیریت یک Domain لازم نیست سیستم‌عامل سرور Endpoint Central حتماً عضو همان Domain باشد.
سه مفهوم که نباید با هم اشتباه شوند
بخش بزرگی از ابهام از اینجا شروع می‌شود که سه موضوع مختلف با یکدیگر یکی فرض می‌شوند:
- عضویت خود سرور Endpoint Central در Windows Domain
- تعریف Active Directory در Scope of Management نرم‌افزار
- عضو Domain بودن یا نبودن دستگاه‌هایی که قرار است مدیریت شوند
این سه مورد مستقل از یکدیگرند. ممکن است سرور Endpoint Central عضو Workgroup باشد، اما ده‌ها یا هزاران سیستم Domain-Joined را مدیریت کند. برعکس، ممکن است سرور عضو Domain باشد ولی تعدادی لپ‌تاپ، سرور یا کامپیوتر Workgroup را نیز تحت مدیریت داشته باشد.
Endpoint Central برای مدیریت Domain واقعاً به چه چیزی نیاز دارد؟
Endpoint Central معماری Agent-based دارد. یعنی برای انجام عملیات مدیریتی، Agent روی Endpoint نصب می‌شود و ارتباط اصلی مدیریت دستگاه از طریق همین Agent انجام می‌شود. برای کشف دستگاه‌ها، همگام‌سازی Active Directory و بعضی روش‌های Push Installation، نرم‌افزار باید بتواند با Domain Controller و سیستم‌های مقصد ارتباط لازم را برقرار کند و Credential مناسب در اختیار داشته باشد.
در کنسول Endpoint Central، Domain یا Workgroup از بخش Scope of Management تعریف می‌شود. برای Active Directory، اطلاعات Domain، Domain Controller و Credential مناسب ثبت می‌شود. برای Workgroup نیز می‌توان Credential محلی دارای سطح دسترسی لازم را تعریف کرد.
می‌تواند عضو Domain باشد یا نباشد. این موضوع به معماری امنیتی و سیاست سازمان بستگی دارد.
در Scope of Management تعریف می‌شود و ارتباط با Domain Controller باید برقرار باشد.
می‌توانند Domain-Joined، Workgroup، شعبه‌ای یا Roaming باشند.
سناریوی اول: سرور Endpoint Central عضو Workgroup است، کلاینت‌ها عضو Domain هستند
این سناریو کاملاً قابل اجراست و در بسیاری از سازمان‌ها حتی از نظر تفکیک امنیتی انتخاب قابل توجهی است.
فرض کنید تمام کامپیوترهای کاربران عضو Active Directory هستند. Endpoint Central را روی یک Windows Server جدا نصب می‌کنید که خودش عضو Domain نیست. در Endpoint Central، Active Directory را اضافه می‌کنید، Domain Controller را معرفی می‌کنید و Credential لازم برای Sync یا نصب Agent را در اختیار نرم‌افزار قرار می‌دهید.
تا زمانی که ارتباط شبکه، DNS، نام‌حل‌کنی، فایروال و سطح دسترسی Credential درست تنظیم شده باشند، عضو Domain نبودن خود سرور مانع مدیریت کلاینت‌های Domain نمی‌شود.
مزیت اصلی این مدل این است که سرور UEM شما وابستگی کمتری به عضویت مستقیم در Domain دارد. اگر سیاست امنیتی سازمان بر جداسازی سامانه‌های مدیریتی حساس از Domain تأکید داشته باشد، این معماری می‌تواند مناسب باشد.
در مقابل باید تنظیمات شبکه و احراز هویت را با دقت بیشتری انجام دهید. اگر DNS اشتباه باشد، Domain Controller قابل دسترس نباشد یا Credential سطح دسترسی کافی نداشته باشد، عملیات کشف یا Push Agent با خطا روبه‌رو می‌شود. این خطا به معنی نیاز به Domain Join کردن سرور نیست؛ معمولاً باید Reachability، Credential و Policyهای ویندوز بررسی شوند.
سناریوی دوم: خود سرور Endpoint Central هم عضو Domain است
این معماری هم کاملاً معتبر است. در بسیاری از شبکه‌های داخلی، مدیران ترجیح می‌دهند سرور Endpoint Central نیز عضو Domain باشد تا مدیریت سیستم‌عامل سرور، اعمال GPOهای سازمانی، DNS و برخی سیاست‌های متمرکز ساده‌تر شود.
اما یک تفاوت مهم وجود دارد: این انتخاب یک تصمیم معماری و عملیاتی است، نه پیش‌نیاز Endpoint Central.
اگر سرور را عضو Domain می‌کنید، باید آن را مثل یک Management Server حساس در نظر بگیرید. Endpoint Central می‌تواند پچ، نرم‌افزار، تنظیمات امنیتی و عملیات مدیریتی را در مقیاس وسیع اجرا کند؛ بنابراین دسترسی به خود سرور باید محدود، لاگ‌گذاری و سخت‌سازی شود.
سناریوی سوم: کلاینت‌ها اصلاً عضو Domain نیستند
Endpoint Central برای شبکه‌های Workgroup هم طراحی شده است. مستندات رسمی ManageEngine صراحتاً اعلام می‌کند که می‌توان کامپیوترهایی را که عضو Domain نیستند مدیریت کرد.
در این حالت معمولاً یک Credential محلی با دسترسی Administrative لازم است و بسته به روش استقرار Agent، ممکن است نیاز باشد تنظیمات UAC، فایروال و دسترسی‌های Remote Administration روی سیستم‌های مقصد بررسی شوند.
برای شبکه‌های Workgroup بزرگ، داشتن یک الگوی یکسان و کنترل‌شده برای Local Admin Credential اهمیت زیادی دارد. استفاده پراکنده از حساب‌های متفاوت روی صدها دستگاه، هم نگهداری را سخت می‌کند و هم احتمال خطای Agent Deployment را بالا می‌برد.
سناریوی چهارم: چند Domain، چند شعبه و سیستم‌های Workgroup
یکی از نقاط قوت معماری Endpoint Central این است که محدود به یک Domain نیست. می‌توانید ترکیبی از چند Active Directory، چند Workgroup، دفاتر راه دور و کاربران Roaming را از یک کنسول مدیریت کنید.
در این معماری معمولاً برای هر Domain یا موقعیت شبکه، Credential و مسیر ارتباطی مناسب تعریف می‌شود. اگر Domain Controller مستقیماً از Central Server قابل دسترس نباشد، در نسخه‌های جدید Endpoint Central می‌توان از Distribution Server نزدیک به Domain Controller به‌عنوان Active Directory Connector استفاده کرد.
این قابلیت از نظر معماری نکته مهمی دارد: ارتباط با AD الزاماً به معنی عضو Domain بودن Central Server نیست؛ حتی مسیر دسترسی به Domain Controller نیز می‌تواند از طریق یک Connector واسط طراحی شود.
چه زمانی عضو Domain کردن سرور می‌تواند منطقی باشد؟
هیچ پاسخ یکسانی برای همه سازمان‌ها وجود ندارد. عضو Domain کردن سرور می‌تواند در شرایط زیر از نظر عملیات داخلی ساده‌تر باشد:
- تمام سرورهای مدیریتی سازمان طبق استاندارد داخلی باید عضو Domain باشند.
- Hardening، Audit Policy و تنظیمات Windows Server از طریق GPO مرکزی اعمال می‌شود.
- مدیریت DNS، نام‌حل‌کنی و دسترسی‌های داخلی در محیط Domain استاندارد و پایدار شده است.
- تیم زیرساخت می‌خواهد چرخه Patch، Backup و کنترل دسترسی خود سرور را با همان سیاست سایر Member Serverها مدیریت کند.
در این حالت عضویت در Domain می‌تواند کار مدیریت سیستم‌عامل سرور را ساده‌تر کند، ولی همچنان نباید آن را با Credentialهایی که Endpoint Central برای مدیریت Endpointها استفاده می‌کند یکی دانست.
چه زمانی مستقل نگه داشتن سرور جذاب‌تر است؟
در بعضی معماری‌های امنیتی، UEM، Backup Server، PAM، SIEM یا سامانه‌های مدیریتی حساس را عمداً از عضویت مستقیم در Production Domain جدا نگه می‌دارند تا در صورت رخداد امنیتی، همه اجزای مدیریتی در یک Trust Boundary قرار نگیرند.
برای Endpoint Central نیز چنین طراحی‌ای قابل بررسی است، به شرط آنکه:
- ارتباط کنترل‌شده با Domain Controller و Endpointها برقرار باشد.
- DNS و Time Synchronization صحیح باشند.
- Credentialها با اصل Least Privilege مدیریت شوند.
- پورت‌های لازم فقط بین مبدأ و مقصدهای موردنیاز باز باشند.
- دسترسی مدیریتی به خود سرور محدود به تیم مجاز باشد.
موضوع مهم‌تر از Domain Join: Credentialها
در عمل، بسیاری از مشکلاتی که به اشتباه به «عضو Domain نبودن سرور» نسبت داده می‌شوند، از Credential یا دسترسی شبکه ناشی می‌شوند.
طبق مستندات ManageEngine، برای اضافه کردن Active Directory می‌توان Credential مرتبط با Domain را تعریف کرد. برای بعضی عملیات مانند Push Installation Agent باید حساب مورد استفاده سطح دسترسی مدیریتی لازم روی سیستم‌های مقصد را داشته باشد. در مقابل، برای AD Sync صرف می‌توان از حسابی استفاده کرد که صرفاً دسترسی لازم برای همگام‌سازی را دارد؛ در این حالت Push Installation از کنسول با همان حساب انجام نمی‌شود.
اشتباه رایج: اینکه چون برای نصب Agent به دسترسی مدیریتی نیاز داریم، نتیجه بگیریم خود Windows Server میزبان Endpoint Central هم باید Domain-Joined باشد. این دو موضوع ارتباط الزامی با هم ندارند.
آیا برای نصب Agent حتماً Domain لازم است؟
خیر. Endpoint Central چند روش برای نصب Agent دارد. در شبکه Domain می‌توان از روش‌هایی مانند Push Installation یا Group Policy استفاده کرد. در Workgroup نیز امکان اضافه کردن و نصب Agent وجود دارد و می‌توان از روش‌های دستی یا سایر روش‌های استقرار استفاده کرد.
اگر تعداد سیستم‌ها زیاد است و Active Directory ساختار منظم OU و GPO دارد، استفاده از روش‌های مبتنی بر Domain می‌تواند استقرار اولیه Agent را ساده‌تر کند. برای مطالعه جزئیات این موضوع، مقاله نصب ایجنت‌ها با استفاده از گروپ پالیسی را هم ببینید.
آیا Endpoint Central باید مستقیماً Domain Controller را ببیند؟
در معماری ساده، Central Server با Domain Controller ارتباط دارد. اما مستندات جدید ManageEngine برای شرایطی که Domain Controller مستقیماً در دسترس Central Server نیست، استفاده از Active Directory Connector را پیش‌بینی کرده است. یک Distribution Server نزدیک به Domain Controller می‌تواند این نقش را برعهده بگیرد.
این مدل برای شعب، شبکه‌های Segmented یا سازمان‌هایی با چند Site مفید است. برای طراحی بهتر ساختار شعب، مقاله راه‌اندازی سرور توزیع در Endpoint Central را مطالعه کنید.
مقایسه سه معماری رایج
| معماری | قابل اجرا؟ | نکته اصلی |
|---|---|---|
| سرور Endpoint Central عضو Domain و کلاینت‌ها عضو همان Domain | بله | مدیریت سیستم‌عامل سرور در ساختار AD ساده‌تر است، اما Domain Join الزام محصول نیست. |
| سرور Endpoint Central عضو Workgroup و کلاینت‌ها عضو Domain | بله | Domain در Scope of Management تعریف می‌شود؛ Credential، DNS و Reachability مهم‌اند. |
| سرور مستقل و کلاینت‌ها Workgroup | بله | Credential محلی و روش مناسب استقرار Agent لازم است. |
| یک سرور برای چند Domain و Workgroup | بله | هر شبکه و Credential به‌صورت جداگانه مدیریت می‌شود. |
| Domain Controller مستقیماً از Central Server قابل دسترس نیست | بله، با طراحی مناسب | می‌توان از Distribution Server به‌عنوان AD Connector استفاده کرد. |
پیشنهاد معماری برای محیط‌های سازمانی حساس
اگر هدف فقط این است که Endpoint Central «کار کند»، هر دو مدل Domain-Joined و Workgroup می‌توانند درست باشند. اما اگر هدف طراحی حرفه‌ای است، بهتر است تصمیم را بر اساس سطح ریسک بگیرید.
یک الگوی قابل دفاع این است که Endpoint Central را در یک Management VLAN قرار دهید، دسترسی ورودی به کنسول را محدود کنید، ارتباط موردنیاز با Domain Controller و Endpointها را فقط روی پورت‌های ضروری مجاز کنید و حساب‌های مورد استفاده برای AD Sync و Agent Deployment را تا حد امکان از یکدیگر تفکیک کنید.
همچنین TLS، Backup منظم، کنترل دسترسی Administratorها، به‌روزرسانی خود Endpoint Central و مانیتورینگ لاگ‌های مدیریتی اهمیت بیشتری از این دارد که صرفاً سرور را عضو Domain کنید یا نکنید.
برای بررسی ارتباطات و پورت‌ها می‌توانید مقاله معماری و لیست پورت‌های نرم‌افزار ManageEngine Endpoint Central را ببینید.
چک‌لیست قبل از تصمیم‌گیری
- محل نصب سرور را مشخص کنید. شبکه داخلی، VLAN مدیریتی، دیتاسنتر یا بخش جداشده؟
- Domain Controllerهای موردنیاز را مشخص کنید. آیا Central Server مستقیماً به آن‌ها دسترسی دارد؟
- DNS را تست کنید. نام Domain، DC و Endpointها باید به‌درستی Resolve شوند.
- Credentialها را طراحی کنید. حساب AD Sync و حساب موردنیاز برای Push Agent را بر اساس حداقل دسترسی لازم انتخاب کنید.
- روش نصب Agent را مشخص کنید. Push، GPO، نصب دستی، Distribution Server یا روش‌های دیگر.
- پورت‌ها و Firewall Ruleها را مستند کنید. بازکردن گسترده فایروال جایگزین طراحی درست نیست.
- Backup و Recovery را از روز اول فعال کنید. Endpoint Central یک سامانه مدیریتی حیاتی است.
- دسترسی به کنسول را محدود کنید. تعداد Administratorها و Roleهای آن‌ها را کنترل کنید.
چند سؤال پرتکرار
اگر سرور Endpoint Central عضو Domain نباشد، می‌تواند سیستم‌های Domain را Patch کند؟
بله. پس از نصب Agent و برقراری ارتباط صحیح، مدیریت Endpoint به عضو Domain بودن خود سرور وابسته نیست. Domain برای Discovery، Sync و بعضی روش‌های Deployment نقش دارد، اما خود Central Server لازم نیست Domain-Joined باشد.
اگر سیستم مقصد عضو Domain نباشد چه؟
قابل مدیریت است. ManageEngine در FAQ رسمی Endpoint Central صراحتاً مدیریت کامپیوترهایی را که عضو Domain نیستند پشتیبانی می‌کند.
آیا می‌توان چند Domain را با یک Endpoint Central مدیریت کرد؟
بله. معماری Endpoint Central از Multiple Domains، Workgroupها و ترکیب آن‌ها پشتیبانی می‌کند. هر Domain باید با اطلاعات و Credential مناسب در Scope of Management تعریف شود.
آیا همه Endpointها باید اینترنت داشته باشند؟
خیر. طبق FAQ رسمی ManageEngine، همه Managed Computerها الزاماً به اینترنت مستقیم نیاز ندارند. Central Server برای دریافت Patchها و بسته‌های نرم‌افزاری از Vendorها ممکن است به اینترنت نیاز داشته باشد و سپس محتوا را در معماری داخلی توزیع کند.
آیا برای ورود Technicianها با حساب Active Directory باید خود سرور عضو Domain باشد؟
Endpoint Central امکان Active Directory-based Technician Login را از طریق AD Integration فراهم می‌کند. این قابلیت را باید از مفهوم عضویت سیستم‌عامل سرور در Domain جدا دید؛ احراز هویت Technician در سطح Application و AD Integration تنظیم می‌شود.
برای شروع از کجا بخوانیم؟
اگر در حال طراحی Endpoint Central از صفر هستید، پیشنهاد می‌شود ابتدا راهنمای ادمین Endpoint Central را مطالعه کنید. برای انتخاب مدل پیاده‌سازی نیز مقاله کدام مدل پیاده‌سازی Endpoint Central مناسب سازمان شماست؟ مکمل خوبی برای این بحث است.
همچنین صفحه راهنمای کامل محصول Endpoint Central نقطه ورود مناسبی برای شناخت قابلیت‌های اصلی محصول است.
سخن پایانی
برای راه‌اندازی Endpoint Central، لازم نیست صرفاً به این دلیل که کلاینت‌های شما عضو Active Directory هستند، خود سرور Endpoint Central را هم وارد Domain کنید. نرم‌افزار Domain را از طریق Scope of Management، Credential و ارتباط با Domain Controller می‌شناسد و Agentها عملیات مدیریتی را روی Endpointها اجرا می‌کنند.
پس سؤال درست این نیست که «آیا Endpoint Central بدون Domain Join کار می‌کند؟»؛ پاسخ این سؤال بله است. سؤال مهم‌تر این است که برای معماری امنیتی سازمان شما، سرور مدیریتی بهتر است داخل همان Trust Boundary قرار بگیرد یا به‌صورت مستقل در یک شبکه مدیریتی کنترل‌شده نگهداری شود؟
اگر جداسازی امنیتی اولویت بالاتری دارد، Workgroup بودن سرور کاملاً قابل بررسی است. اگر استاندارد عملیاتی سازمان مدیریت همه Member Serverها از طریق Domain است، Domain Join هم انتخاب معتبری است. در هر دو حالت، Credential، Firewall، DNS، TLS و دسترسی Administratorها تعیین‌کننده‌تر از خود Domain Join هستند.
برای معماری Endpoint Central سازمان خودتان مطمئن نیستید؟
قبل از نصب، تعداد Endpointها، تعداد Domainها، شعب، روش نصب Agent، دسترسی اینترنت، سیاست امنیتی و مسیر ارتباط با Domain Controller را مشخص کنید. این چند تصمیم، معماری نهایی را بسیار بیشتر از عضو Domain بودن یا نبودن سرور تعیین می‌کنند.
درخواست جلسه بررسی و دمو · استعلام لایسنس ManageEngine · معرفی Endpoint Central
