کاربر صبح با حساب دامنه وارد ویندوز میشود، مرورگر را باز میکند و آدرس ServiceDesk Plus را میزند. انتظار طبیعی این است که سامانه دوباره همان نام کاربری و رمز عبور Active Directory را نپرسد؛ کاربر باید مستقیماً وارد پنل خودش شود.
این سناریو در ManageEngine ServiceDesk Plus قابل پیادهسازی است. در نسخههای جدید، معماری پیشنهادی این است: Windows Domain Login → AD FS → SAML → ServiceDesk Plus. در این مدل ServiceDesk Plus نقش Service Provider یا SP را دارد، AD FS نقش Identity Provider یا IdP را ایفا میکند و Windows Integrated Authentication باعث میشود کاربر دامنه در شبکه داخلی، بدون تایپ دوباره رمز عبور احراز هویت شود.
پاسخ کوتاه: بله، بدون صفحه لاگین ممکن است
اگر کاربران ServiceDesk Plus از Active Directory وارد شده باشند و رایانههای سازمان نیز با همان دامنه Windows احراز هویت شوند، میتوان SSO را طوری تنظیم کرد که کاربر پس از باز کردن لینک سامانه مستقیماً وارد Requester Portal خودش شود.
نکته مهم این است که Import شدن کاربران از Active Directory بهتنهایی SSO ایجاد نمیکند. Import مشخصات کاربر را به ServiceDesk Plus میآورد؛ اما برای ورود بدون درخواست مجدد Username و Password باید یک لایه احراز هویت یکپارچه مانند SAML با AD FS پیکربندی شود.
چرا دیگر سراغ NTLM Pass-through نرویم؟
در نسخههای قدیمی ServiceDesk Plus، NTLM SSO یا Pass-through Authentication روشی رایج بود. اما طبق Release Notes رسمی ManageEngine، از Build 13000 پشتیبانی NTLM SSO متوقف شده و برای SSO استفاده از SAML توصیه شده است.
بنابراین در استقرارهای جدید، بهخصوص سری 15، طراحی جدید را روی NTLM بنا نکنید. اگر سازمان هنوز از نسخه قدیمی استفاده میکند، پیش از هر تغییر مسیر ارتقا نیز باید بررسی شود. برای آشنایی با نسخههای جدید میتوانید صفحه دانلود ServiceDesk Plus را ببینید.
معماری پیشنهادی برای سازمانهای دارای Active Directory
جریان ورود به شکل زیر است:
- کاربر با حساب DOMAIN\username وارد Windows میشود.
- کاربر آدرس ServiceDesk Plus را در Edge یا Chrome باز میکند.
- ServiceDesk Plus برای احراز هویت SAML، مرورگر را به AD FS هدایت میکند.
- AD FS با Windows Integrated Authentication هویت کاربر فعلی ویندوز را تشخیص میدهد.
- AD FS یک SAML Assertion معتبر برای ServiceDesk Plus صادر میکند.
- ServiceDesk Plus کاربر را با Requester یا Technician موجود تطبیق میدهد و پنل همان شخص باز میشود.
این Redirect معمولاً بسیار سریع است و در تجربه کاربر مانند ورود مستقیم دیده میشود؛ یعنی کاربر صفحهای برای تایپ دوباره رمز مشاهده نمیکند.
پیشنیازهای اصلی
- رایانههای کاربران عضو Domain باشند و کاربر با حساب AD وارد Windows شده باشد.
- کاربران موردنظر در ServiceDesk Plus وجود داشته باشند و ترجیحاً از همان Active Directory Import یا Sync شده باشند.
- ServiceDesk Plus با HTTPS و نام DNS پایدار در دسترس باشد.
- AD FS نصب و به Active Directory متصل باشد.
- نام کاربری، UPN یا Email ارسالی در SAML با شناسه کاربر موجود در ServiceDesk Plus تطابق داشته باشد.
- کلاینتها بتوانند AD FS را با نام FQDN صحیح Resolve و از طریق HTTPS باز کنند.
تنظیم SAML در ServiceDesk Plus
در ServiceDesk Plus با دسترسی SDAdmin به بخش Admin → Users & Permissions → Single Sign On → SAML SSO بروید و SAML Single Sign-On را فعال کنید. طبق راهنمای رسمی SAML در ServiceDesk Plus، سامانه اطلاعات Service Provider از جمله Entity ID و Assertion Consumer URL را برای معرفی به IdP ارائه میکند.
این مقادیر باید در AD FS بهعنوان Relying Party Trust ثبت شوند. سپس Login URL، Certificate و سایر اطلاعات IdP از AD FS به ServiceDesk Plus برگردانده میشود.
مهمترین بخش: تطبیق درست کاربر
بیشتر خطاهای عملی SSO نه از SAML، بلکه از Identity Mapping میآیند. فرض کنید کاربر در AD با UPN زیر شناخته میشود:
ali.rezaei@company.local
اما Login Name او در ServiceDesk Plus به شکل زیر ثبت شده است:
ali.rezaei
اگر NameID یا Claim ارسالی از AD FS با فیلدی که ServiceDesk Plus انتظار دارد همخوان نباشد، ورود میتواند شکست بخورد یا در بعضی پیکربندیها رکورد کاربر دیگری ایجاد شود. بنابراین پیش از Rollout سراسری، یک Requester و یک Technician واقعی را بررسی کنید و مشخص کنید شناسه مرجع شما کدام است: Login Name، UPN یا Email.
قاعده ساده این است: هویت SAML باید به همان رکوردی برسد که قبلاً از AD وارد ServiceDesk Plus شده است.
Windows Integrated Authentication چه نقشی دارد؟
SAML بهتنهایی تضمین نمیکند که کاربر هیچ رمزی وارد نکند. بخش دوم ماجرا Windows Integrated Authentication یا WIA در AD FS است. مایکروسافت در مستند رسمی AD FS توضیح میدهد که WIA برای درخواستهای احراز هویت شبکه داخلی قابل استفاده است و مرورگر میتواند هویت Windows کاربر را بدون ورود دستی مجدد به AD FS ارائه کند.
برای Edge، آدرس AD FS باید در محدودهای باشد که مرورگر اجازه Integrated Authentication به آن میدهد؛ Microsoft Edge بهصورت پیشفرض از Intranet Zone استفاده میکند و در صورت نیاز میتوان سیاست AuthServerAllowlist را از طریق Group Policy اعمال کرد. برای Chrome و برخی سناریوهای AD FS نیز ممکن است تنظیم WIA Supported User Agents یا Policy مرورگر لازم باشد. جزئیات در مستند Windows Integrated Authentication مایکروسافت آمده است.
نمونه تجربه نهایی کاربر
کاربر «علی رضایی» روی سیستم سازمان با حساب COMPANY\alirezaei وارد Windows شده است. او Edge را باز میکند و آدرس ServiceDesk Plus را میزند. سامانه او را به AD FS هدایت میکند؛ AD FS هویت Windows جاری را با WIA تشخیص میدهد، SAML Assertion صادر میکند و ServiceDesk Plus کاربر را به رکورد «علی رضایی» متصل میکند.
نتیجه این است که پنل کاربری علی رضایی بدون نمایش فرم Username/Password باز میشود. اگر کاربر دیگری با حساب Windows خودش وارد همان رایانه شود، پنل همان کاربر دوم نمایش داده خواهد شد.
چه زمانی ممکن است کاربر همچنان صفحه ورود ببیند؟
| وضعیت | علت محتمل |
|---|---|
| AD FS نام کاربری و رمز میخواهد | WIA فعال نیست، مرورگر یا Intranet Zone درست تنظیم نشده یا دستگاه خارج از شبکه مورد اعتماد است. |
| ServiceDesk Plus بعد از SAML کاربر را نمیشناسد | NameID یا Claim با Login Name، UPN یا Email کاربر موجود تطابق ندارد. |
| در Edge کار میکند ولی در Chrome نه | Policy یا User Agent مربوط به Integrated Authentication نیاز به تنظیم دارد. |
| SSO داخل شبکه کار میکند ولی از اینترنت نه | WIA معمولاً برای سناریوی Intranet طراحی شده و مسیر Extranet میتواند Authentication Policy متفاوت داشته باشد. |
| پس از Reverse Proxy پنجره 401 دیده میشود | Proxy، SSL Bridging یا تنظیمات Kerberos/Extended Protection میتواند در WIA اختلال ایجاد کند. |
چکلیست اجرای امن
SSO را یکباره برای همه کاربران فعال نکنید. ابتدا با یک گروه کوچک Pilot شامل یک Requester عادی، یک Technician و یک Administrator آزمایش کنید. Login، Logout، تغییر کاربر Windows، Expire شدن Session و رفتار مرورگرهای اصلی سازمان را کنترل کنید.
همچنین حداقل یک حساب Local Administrator را بهعنوان Break-glass Account حفظ کنید. اگر روزی AD FS، DNS، Certificate یا ارتباط Domain دچار مشکل شد، مدیر سامانه باید همچنان راه ورود مستقل به ServiceDesk Plus داشته باشد.
پس از تأیید SSO میتوانید تجربه کاربری را با بومیسازی رابط نیز تکمیل کنید. بسته فارسیساز و تقویم شمسی ServiceDesk Plus مدانت برای سری 15 مستقل از مکانیزم SAML کار میکند؛ یعنی احراز هویت یکپارچه و بومیسازی رابط دو لایه جدا از هم هستند.
آیا AD FS تنها انتخاب است؟
خیر. ServiceDesk Plus از SAML 2.0 استفاده میکند و میتواند با Identity Providerهای سازگار دیگر نیز یکپارچه شود. اگر سازمان زیرساخت Microsoft Entra ID یا IdP دیگری دارد، طراحی SSO میتواند بر همان اساس انجام شود. اما برای سازمانی که رایانهها Domain Joined هستند و هدف آن استفاده مستقیم از Windows Authentication در شبکه داخلی است، AD FS همراه با WIA یک معماری روشن و قابل کنترل است.
سخن پایانی
ورود یکپارچه فقط حذف یک فرم لاگین نیست؛ اتصال درست هویت Windows به میز خدمت است. وقتی Active Directory، AD FS، SAML و شناسه کاربران ServiceDesk Plus دقیقاً با هم منطبق باشند، کاربر وارد ویندوز میشود، لینک میز خدمت را باز میکند و بدون توقف وارد پنل خودش میشود. SSO خوب همان احراز هویتی است که کاربر حضورش را حس نمیکند، اما تیم IT کنترل و امنیت آن را کاملاً میبیند.
