USERS(5) FreeRADIUS user authorization file USERS(5)

users - فایل مجوزدهی کاربران برای کارساز FreeRADIUS

فایل‌های users در دایرکتوری پیکربندی ماژول files، به‌طور پیش‌فرض در /etc/raddb/mods-config/files/ قرار دارند. این فایل شامل مجموعه‌ای از دستورالعمل‌های پیکربندی است که توسط ماژول files برای تصمیم‌گیری درباره نحوهٔ احراز هویت و مجوزدهی به هر درخواست کاربر استفاده می‌شود.

هر خطی که با علامت هش ('#') شروع شود به عنوان کامنت در نظر گرفته شده و نادیده گرفته می‌شود.

هر مدخل (entry) از فایل با یک نام کاربری شروع می‌شود، که به دنبال آن فهرستی (احتمالاً خالی) از موارد بررسی (check items) می‌آید، همگی در یک خط. خط بعدی با یک نویسهٔ تب (tab) و فهرستی (احتمالاً خالی) از موارد پاسخ (reply items) آغاز می‌شود. هر مورد در فهرست موارد بررسی یا پاسخ، یک ویژگی (صفت یا attribute) به فرم name = value است. چندین مورد می‌توانند در یک خط قرار گیرند، که در این صورت باید با کاما از هم جدا شوند. موارد پاسخ ممکن است در چندین خط مشخص شوند، که در این حالت هر خط باید با یک کاما پایان یابد و آخرین خط از موارد پاسخ نباید با کاما پایان یابد.

موارد بررسی، فهرستی از ویژگی‌ها هستند که برای مطابقت با درخواست ورودی استفاده می‌شوند. اگر نام کاربری مطابقت داشته باشد، و تمام موارد بررسی نیز با درخواست ورودی تطابق داشته باشند، آنگاه موارد پاسخ به فهرست ویژگی‌هایی که در پاسخ به آن درخواست ارسال خواهند شد اضافه می‌شوند. این فرآیند برای تمام مدخل‌های موجود در فایل users تکرار می‌شود.

اگر درخواست ورودی با هیچ مدخلی مطابقت نداشته باشد، آنگاه درخواست رد (reject) می‌شود.

کلیدواژهٔ ویژهٔ DEFAULT با تمام نام‌های کاربری مطابقت دارد.

مدخل‌ها به ترتیب، از بالای فایل users به سمت پایین پردازش می‌شوند. اگر یک مدخل شامل ویژگی ویژهٔ Fall-Through = No در بخش پاسخ باشد، پردازش فایل متوقف شده و هیچ مدخل دیگری بررسی نمی‌شود. با هر فهرست مورد پاسخ که فاقد ویژگی Fall-Through باشد، به گونه‌ای رفتار می‌شود که گویی ویژگی Fall-Through = No را داراست.

اگر یک مدخل شامل ویژگی ویژهٔ Fall-Through = Yes به عنوان صفت پاسخ باشد، پردازش به ترتیب به مدخل بعدی ادامه می‌یابد.

هنگام استفاده از Fall-Through باید احتیاط کرد. کارساز باید در حالت اشکال‌زدایی (debugging) با تعدادی درخواست آزمایشی بررسی شود تا اطمینان حاصل گردد که مدخل‌های پیکربندی‌شده طبق انتظار عمل می‌کنند.

ویژگی ویژهٔ Auth-Type برای مشخص کردن نوع احراز هویت مورد استفاده برای آن کاربر به کار می‌رود. برای مشاهدهٔ فهرست مقادیر مجاز ویژگی Auth-Type به فایل dictionary مراجعه کنید.

پس از پردازش فایل users، درخواست با استفاده از روش تعیین‌شده توسط Auth-Type احراز هویت می‌شود.

علاوه بر =، ممکن است عملگرهای دیگری نیز برای ویژگی‌ها در فهرست موارد بررسی یا موارد پاسخ استفاده شوند. در ادامه فهرستی از عملگرها و معانی آن‌ها آمده است:

به عنوان یک مورد بررسی برای ویژگی‌های پروتکل RADIUS مجاز نیست. برای ویژگی‌های پیکربندی کارساز (مانند Auth-Type و غیره) مجاز است و مقدار یک ویژگی را تنها در صورتی تنظیم می‌کند که هیچ مورد دیگری از همان ویژگی وجود نداشته باشد.
به عنوان یک مورد پاسخ، به این معناست: «این مورد را به فهرست پاسخ اضافه کن، اما فقط اگر هیچ مورد دیگری از همان ویژگی وجود نداشته باشد.»
به عنوان یک مورد بررسی همواره مطابقت می‌یابد، و در موارد پیکربندی هر ویژگی با همان نام را جایگزین می‌کند. اگر هیچ ویژگی‌ای با آن نام در درخواست ظاهر نشود، این ویژگی اضافه می‌گردد.
به عنوان یک مورد پاسخ، معنایی مشابه دارد، اما این عمل به جای موارد درخواست، برای موارد پاسخ اعمال می‌شود.
به عنوان یک مورد بررسی، در صورتی مطابقت دارد که ویژگی نام‌برده در درخواست موجود باشد، و مقدار داده‌شده را نیز داشته باشد.
به عنوان یک مورد پاسخ مجاز نیست.
به عنوان یک مورد بررسی همواره مطابقت می‌یابد، و ویژگی جاری را با مقدار مشخص به انتهای فهرست موارد پیکربندی اضافه می‌کند.
به عنوان یک مورد پاسخ، معنایی مشابه دارد، اما ویژگی به انتهای فهرست موارد پاسخ اضافه می‌شود.
به عنوان یک مورد بررسی همواره مطابقت می‌یابد، و ویژگی جاری را با مقدار مشخص به ابتدای فهرست موارد پیکربندی اضافه می‌کند.
به عنوان یک مورد پاسخ، معنایی مشابه دارد، اما ویژگی به ابتدای فهرست موارد پاسخ اضافه می‌شود.
به عنوان یک مورد بررسی، در صورتی مطابقت دارد که ویژگی داده‌شده در درخواست موجود باشد، و دارای مقدار داده‌شده نباشد.
به عنوان یک مورد پاسخ مجاز نیست.
به عنوان یک مورد بررسی، در صورتی مطابقت دارد که درخواست شامل ویژگی‌ای با مقداری بزرگ‌تر از مقدار داده‌شده باشد.
به عنوان یک مورد پاسخ مجاز نیست.
به عنوان یک مورد بررسی، در صورتی مطابقت دارد که درخواست شامل ویژگی‌ای با مقداری بزرگ‌تر یا مساوی با مقدار داده‌شده باشد.
به عنوان یک مورد پاسخ مجاز نیست.
به عنوان یک مورد بررسی، در صورتی مطابقت دارد که درخواست شامل ویژگی‌ای با مقداری کوچک‌تر از مقدار داده‌شده باشد.
به عنوان یک مورد پاسخ مجاز نیست.
به عنوان یک مورد بررسی، در صورتی مطابقت دارد که درخواست شامل ویژگی‌ای با مقداری کوچک‌تر یا مساوی با مقدار داده‌شده باشد.
به عنوان یک مورد پاسخ مجاز نیست.
به عنوان یک مورد بررسی، در صورتی مطابقت دارد که درخواست شامل ویژگی نام‌برده باشد، بدون توجه به این که مقدار آن چه باشد.
به عنوان یک مورد پاسخ مجاز نیست.
به عنوان یک مورد بررسی، در صورتی مطابقت دارد که درخواست فاقد ویژگی نام‌برده باشد، بدون توجه به این که مقدار آن چه باشد.
به عنوان یک مورد پاسخ مجاز نیست. 

bob	Cleartext-Password := "hello"
درخواست‌های حاوی ویژگی User-Name با مقدار «bob»، با استفاده از گذرواژهٔ معتبر «hello» احراز هویت خواهند شد. هیچ مورد پاسخی وجود ندارد، بنابراین پاسخ ارسالی خالی خواهد بود.
DEFAULT Service-Type == Framed-User, Framed-Protocol == PPP
	Service-Type = Framed-User,
	Framed-Protocol = PPP,
	Fall-Through = Yes
اگر بستهٔ درخواست حاوی ویژگی‌های Service-Type و Framed-Protocol با مقادیر داده‌شده باشد، آنگاه این ویژگی‌ها در پاسخ گنجانده می‌شوند.

یعنی به کاربر همان چیزی که درخواست کرده داده می‌شود. این مدخل همچنین نحوهٔ تعیین چندین مورد پاسخ را نشان می‌دهد.

برای مثال‌ها و توضیحات بیشتر، فایل users ارائه‌شده همراه با کارساز را مشاهده کنید.

کارساز را در حالت اشکال‌زدایی (-X) اجرا کنید، و از برنامهٔ radclient برای ارسال بسته‌های آزمایشی که فکر می‌کنید با مدخل‌های خاصی مطابقت دارند استفاده نمایید. کارساز چاپ خواهد کرد که کدام مدخل‌ها برای آن درخواست مطابقت داشته‌اند، تا بتوانید صحت انتظارات خود را ارزیابی کنید. این باید نخستین کاری باشد که در صورت شک داشتن به وجود مشکل در فایل انجام می‌دهید.

هنگام نوشتن مدخل‌ها برای فایل users باید دقت زیادی به خرج داد. پیکربندی نادرست کارساز به گونه‌ای که درخواست‌ها در زمان تمایل شما به رد آن‌ها پذیرفته شوند، بسیار محتمل است. مدخل‌ها باید مرتب باشند و مورد Fall-Through فقط در جایی که واقعاً نیاز است استفاده شود.

مدخل‌هایی که درخواست‌های خاصی را رد می‌کنند باید در بالای فایل قرار گیرند و نباید در موارد پاسخ خود دارای Fall-Through باشند. مدخل‌های مربوط به کاربران خاص که فاقد Fall-Through هستند باید در ادامه بیایند. هرگونه مدخل DEFAULT معمولاً باید در پایان قرار گیرد، مگر در مورد مدخل‌های دارای Fall-Through که ویژگی‌های پاسخ را مقداردهی می‌کنند.

/etc/raddb/mods-config/files/

radclient(1), radiusd(8), dictionary(5)

تیم FreeRADIUS (The FreeRADIUS team).

04 Jan 2004