احراز هویت LDAP در OpenVPN کار می‌کند اما بررسی گروه شکست می‌خورد: کجا را ببینیم

اعتبارنامه‌ها می‌گذرند، تونل شروع به بالا آمدن می‌کند و سپس نشست با پیامی درباره گروه و نه درباره گذرواژه شکست می‌خورد. این ترکیب خرابی را در نیمه دوم کار افزونه LDAP قرار می‌دهد: اتصال و بررسی گذرواژه موفق شدند و تصمیم عضویت که پس از آن می‌آید موفق نشد. هر دو نیمه از یک بلوک پیکربندی می‌خوانند، به همین دلیل اصلاح در یک جا می‌تواند دیگری را دست‌نخورده بگذارد. از خط گزارش که نام مرحله را می‌آورد شروع کنید، نه از حسابی که تصادفاً با آن آزمایش می‌کنید.

رد شدن را پاسخی درباره مجوز بدانید

افزونه یک اتصال سرویس انجام می‌دهد، حساب را جست‌وجو می‌کند، گذرواژه ارائه‌شده را بررسی می‌کند و سپس می‌پرسد آیا آن حساب به گروه مجاز تعلق دارد. اینها چهار عملیات جداگانه‌اند و تنها آخری درباره گروه‌هاست. بنابراین ردی که پس از یک اتصال موفق می‌رسد درباره گذرواژه چیزی نمی‌گوید، حتی وقتی کارخواه خطای احراز هویت عمومی نشان می‌دهد. بالا بردن سطح گزارش افزونه پیش از تغییر پیکربندی همان چیزی است که آن چهار را در خروجی از هم جدا می‌کند.

خود ارزیابی گروه را بجویید. وقتی هیچ پرس‌وجوی گروهی پدیدار نمی‌شود، بلوک مجوز اصلاً به‌دست نمی‌آید، که معمولاً یعنی یک دستور بیرون از بلوکی است که مالک آن است یا یک گزینه لازم کم است. وقتی پرس‌وجو پدیدار می‌شود و چیزی برنمی‌گرداند، نقطه پایانی یا پالایه به پرسشی متفاوت از آنچه در نظر داشتید پاسخ می‌دهد.

تصمیم بگیرید که عضویت در پالایه زندگی می‌کند یا در بلوک گروه

دو شکل پشتیبانی‌شده وجود دارد و آمیختن آنها همان راهی است که یک پیکربندی کارآمد از کار می‌افتد. نخستین شکل عضویت را با درخواست صفتی روی شیء کاربر به جست‌وجوی کاربر می‌راند؛ دومی جست‌وجوی کاربر را به حال خود می‌گذارد و افزونه را وامی‌دارد که بعداً شیء گروه را جست‌وجو کند. برای هر استقرار یکی را انتخاب کنید و بنویسید کدام را برگزیده‌اید.

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Access,OU=Groups,DC=example,DC=org))"
    RequireGroup false
</Authorization>

با این شکل پالایه همه چیز را تعیین می‌کند، پس RequireGroup باید false باشد وگرنه افزونه به جست‌وجوی شیء گروهی می‌رود که پالایه هرگز از آن نام نبرده است. صفت درون پالایه باید روی شیء کاربر وجود داشته باشد و پر شده باشد، که با تودرتو شدن گروه‌ها تضمین نمی‌شود.

شکل دیگر جست‌وجو را ساده نگه می‌دارد و پس از آن یک جست‌وجوی گروه می‌افزاید. شیء گروه به‌روشنی نام‌گذاری می‌شود و افزونه کاربر را با اعضایی که دایرکتوری برای آن برمی‌گرداند مقایسه می‌کند. هیچ چیز در پالایه کاربر تغییر نمی‌کند، که این شکل را هرگاه تیم دیگری گروه را مدیریت کند آسان‌تر برای بازرسی می‌کند.

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(sAMAccountName=%u)"
    RequireGroup true
    Group        "CN=VPN Access,OU=Groups,DC=example,DC=org"
</Authorization>

نقطه کور مشترک است: مقایسه ساده عضویت گروه‌های تودرتو را باز نمی‌کند، پس حسابی که دسترسی‌اش از طریق گروه والد می‌آید شکست می‌خورد در حالی که کنسول هنوز عضویت را نشان می‌دهد. Active Directory صفت member را روی گروه آشکار می‌کند، طرح‌واره‌های دیگر از uniqueMember استفاده می‌کنند، و اشاره به صفت نادرست به‌جای خطا نتیجه خالی برمی‌گرداند.

نقطه پایانی برگزینید که شیء گروه را نگه می‌دارد

نشانی URL تعیین می‌کند افزونه از کدام دایرکتوری می‌پرسد، و یک کنترل‌کننده دامنه روی درگاه 389 تنها برای بافت نام‌گذاری خودش پاسخ می‌دهد. یک کاتالوگ سراسری روی درگاه 3268 برای کل جنگل پاسخ می‌دهد، فقط‌خواندنی و با مجموعه صفات جزئی. وقتی حساب‌ها در یک دامنه و گروه VPN در دامنه دیگری است، یک پرس‌وجوی تک‌دامنه‌ای می‌تواند کاربر را بیابد و باز هم عضویت را از دست بدهد. این همان حالتی است که جابه‌جا کردن نشانی URL به درگاه کاتالوگ رد شدن را حل می‌کند، و همان حالتی است که مردم بیش از حد تعمیم می‌دهند.

مجموعه صفات جزئی همان مرز است: بر صفتی که کاتالوگ نگه نمی‌دارد نمی‌توان پالایش کرد، پس همان تغییر می‌تواند یک استقرار را کار بیندازد و دیگری را خالی برگرداند. پیش از بازنویسی بلوک تأیید کنید که نقطه پایانی برای کاربر و گروه واقعی در عمل چه برمی‌گرداند. ارجاع‌ها و TLS باز هم موضوع‌های جدایی هستند، چون ارجاع باید پیگیری شود و نقطه پایانی که TLS می‌خواهد به فایل‌های اعتماد متناظر نیاز دارد.

وضعیت حساب و دامنه جست‌وجو را در فیلدهای خودشان نگه دارید

پرچم غیرفعال‌سازی به پالایه تعلق دارد، نه به بررسی گروه. در Active Directory این بیت دوم userAccountControl است، و بدون آن شرط یک حساب غیرفعال با گذرواژه معتبر احراز هویت می‌کند و سپس در مرحله گروه شکست می‌خورد، که مانند یک اشکال مجوز به نظر می‌رسد. دامنه جست‌وجو به DN پایه تعلق دارد، چون شروع از ریشه دامنه کندتر است و می‌تواند اشیایی بیرون از واحد سازمانی که قصد پوشش آن را داشتید مطابقت دهد.

حقوق حساب اتصال را هم باریک نگه دارید. حقوق گسترده دایرکتوری یک پالایه بدپیکربندی‌شده را به پرس‌وجوی موفق تبدیل می‌کند و اشکال را تا زمانی که کسی حساب را بازرسی کند پنهان می‌گذارد. عضویت را در خود دایرکتوری تغییر دهید، هرگز در فهرست استثنای محلی، تا غیرفعال کردن حساب برای برداشتن دسترسی کافی باشد. اگر تیم دیگری گروه را مدیریت می‌کند، پیش از نوشتن پالایه بر اساس آن، درباره صفتی که پر می‌کنند توافق کنید.

نتیجه را با سه حساب اثبات کنید

پیکربندی را روی سه هویت اجرا کنید: یک عضو مجاز، یک حساب معتبر بیرون از گروه و حسابی که غیرفعال شده است. اگر هر سه رد شوند، اتصال یا پرس‌وجوی گروه خراب است؛ اگر هر سه پذیرفته شوند، هیچ شرط گروهی اصلاً اعمال نمی‌شود. نتیجه مختلط تنها نتیجه‌ای است که اثبات می‌کند پیکربندی مواردی را که برایتان مهم است از هم تشخیص می‌دهد.

همان سه پاسخ را مستقیم از دایرکتوری بخوانید پیش از آنکه افزونه را سرزنش کنید. پرس‌وجوی نخست صفت گروهی را نشان می‌دهد که پالایه به آن وابسته است، و دومی مقدار کنترل حساب را نشان می‌دهد. DN پایه، حساب و نقطه پایانی خودتان را جایگزین کنید:

ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=alice)" memberOf
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=bob)" userAccountControl

کاربری که memberOf برایش خالی برمی‌گردد یک واقعیت دایرکتوری است، نه اشکال افزونه، و حسابی که پس از غیرفعال شدن هنوز احراز هویت می‌کند یعنی پالایه شرط کنترل حساب را ندارد. نخست همان شاهد را درست کنید، سپس آزمون سه‌حسابی را دوباره اجرا کنید. خط گزارش که نام مرحله شکست‌خورده را آورد کنار تغییر پیکربندی نگه دارید، تا نفر بعدی بتواند مجوز را از احراز هویت جدا کند بدون تکرار جست‌وجو.