در مقاله قبل درباره ایجاد Certificate برای استفاده در RDS و RemoteApp صحبت کردیم. می دانیم که گواهینامه امنیتی SSL برای اینکه به درستی عمل نماید نیازمند محتوای مناسب است. برای مثال باید Subject Name و Subject Alternate Name صحیح در آن تعریف شده باشد. در این مقاله اصول مقدار دهی به این فیلدها به صورت خیلی ساده بیان خواهد شد.
در ویندوز ۲۰۰۸ و ۲۰۰۸ نسخه R2 ، شما برای استفاده از سرویس های RDS به Farm Name متصل می شوید که به عنوان DNS Round Robin اولین پیام را به سمت Redirector می فرستد. سپس از آن جا به Connection Broker و سپس به سمت سروری که میزبانی Session شما را انجام می دهد هدایت می شود.
در ویندوز ۲۰۱۲ به بعد اما قضیه سر راست تر از این هاست. ابتدا درخواست به Connection Broker و سپس از آن جا با استفاده از Collection Name به Collection مورد نظر هدایت می گردد!
اشکال از جایی به وجود می آید که در Certificate ای که پیاده سازی می گردد ، بایستی Subject Name یا Subject Alternate Name با نام سروری که به آن متصل می گردد یکی باشد. برای مثال به منظور Publishing در RemoteApp ، گواهینامه امنیتی بایستی نام تمام RDSH Server های موجود در Collection را داشته باشد. ( RDSH مخفف Remote Desktop Server Host ) است.
گواهینامه ای که برای RDWeb استفاده می شود نیز باید حاوی FQDN یا URL ای که کاربران به آن متصل می شوند باشد. اگر شما کاربرانی در خارج از سازمان داشته باشید ، نیاز به یک نام خارجی یا External Name وجود دارد. External Name نیز لزوما بایستی با نامی که به آن متصل می شوند همانند گردد. همچنین اگر کاربران شما از درون شبکه سازمان به RDWeb متصل می شوند ، FQDN یا URL ای که در Certificate آن ها مشخص شده است نیز بایستی با نام سروری که با آن وصل می شوند مشترک باشد.
همچنین جهت Single Sign On مقدار Subject Name می بایست با نام سرور های Collection یکی باشد.
برای مثال فرض کنید که یک اجرای Remote Desktop شامل کامپیوترهای زیر است :
زمانی که کاربران شبکه داخلی FQDN مربوط به سروری که Web Page ها را هاست کرده است ، ( برای مثال RDWEB.CONTOSO.COM ) را وارد می کنند ، نام Certificate باید با مقدار URL برابر باشد. اما ارتباط در همین جا به پایان نمی رسد. درخواست از Web Server به سمت یکی از Session Host ها یا Virtualization Host ها و سپس به Connection Broker هدایت می شود. احتمالا در یک اجرای درست بر روی تمام این سرویس ها ارتباط امن برقرار است. بنابراین همان طور که مشخص است ، برای اینکه گواهینامه امنیتی به درستی عمل نماید ، شما نیاز دارید در فیلد Subject Alternate Name یا SAN نام تمام سرورهای Deployment را وارد نمایید.
بنابراین Certificate مثالی ما احتمالا حاوی اطلاعات تصویر زیر خواهد بود :
مشکلات در همین جا به پایان نمی رسد. اجرای پیچیده تری از RDS را در نظر بگیرید که شما در آن بیشتر از پنج سرور داشته باشید. می دانیم که در فیلد Subject Alternate Name با SAN حداکثر پنج مقدار قرار می گیرد. بنابراین اگر تعداد سرورهای شما از این نیز بیشتر است ، بایستی از Wild Card بهره ببرید.
Wild Card ای که در این مثال مناسب خواهد بود ، اطلاعاتی شبیه مقادیر تصویر زیر را در خود جای داده است :
هنوز یک خبر بد دیگر نیز باقی مانده است. در یک حالت کلاینت های خارج از سازمان با این سناریو نیز به مشکل بر خواهند خورد. در واقع اگر نام دامنه داخلی و خارجی سازمان شما با هم تفاوت داشته باشد ، کاربران خارج از سازمان حتی با وجود Wild Card نمی توانند به درستی از ارتباط امن SSL بهره ببرند.
روشن است که در این حالت اگر Certificate شما دارای مقدار RDWEB.CONTOSO.COM باشد ، Certificate Error دریافت خواهید کرد. چرا که این نام با FQDN سرور اصلی شما در داخل سازمان برابر نیست. ( نام اصلی سرور RDWEB.CONTOSO.LOCAL ) ( دقت داشته باشید که تغییر نام از .com به .local در داخل فایروال یا Router توسط Port Forwarding صورت پذیرفته است )
↵ راه کار : در چنین مواقعی شما می توانید Certificate دومی را از یک Public CA با نام خارجی یا External Name تهیه نمایید. ( در این جا External Name برابر با RDWEB.CONTOSO.COM است ) و آن را به RD Web Access و RD Gateway به اصطلاح Bind نمایید. ( چرا که تنها نقش هایی که در RDS به طور مستقیم با اینترنت در ارتباط هستند ، این دو می باشند )
در این مقاله سعی شد که به بسیاری از سوالات شما متخصصان گرامی درباره استفاده از Certificate در RDS پاسخ ساده و جامعی داده شود. در صورتی که درباره هر کدام از بخش های دیگر این مقاله پرسشی داشته باشید یا با سناریوی دیگری مواجه شده اید ، می توانید آن را در قسمت نظرات مطرح نمایید.
© بیشتر مطالبی که از نظر گذراندید بر اساس داکیومنت رسمی وب سایت مایکروسافت در این آدرس تهیه شده است.
در مقاله بعدی از این سری آموزشی روش معرفی Certificate به Remote Desktop Services را فرا خواهید گرفت.
