Units
Translation components API.
See the Weblate's Web API documentation for detailed description of the API.
GET /api/translations/freeipa/ipa-4-8/uk/units/?format=api&page=7
{ "count": 4657, "next": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/units/?format=api&page=8", "previous": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/units/?format=api&page=6", "results": [ { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nPassword policy\n\nA password policy sets limitations on IPA passwords, including maximum\nlifetime, minimum lifetime, the number of passwords to save in\nhistory, the number of character classes required (for stronger passwords)\nand the minimum password length.\n\nBy default there is a single, global policy for all users. You can also\ncreate a password policy to apply to a group. Each user is only subject\nto one password policy, either the group policy or the global policy. A\ngroup policy stands alone; it is not a super-set of the global policy plus\ncustom settings.\n\nEach group password policy requires a unique priority setting. If a user\nis in multiple groups that have password policies, this priority determines\nwhich password policy is applied. A lower value indicates a higher priority\npolicy.\n\nGroup password policies are automatically removed when the groups they\nare associated with are removed.\n\nEXAMPLES:\n\n Modify the global policy:\n ipa pwpolicy-mod --minlength=10\n\n Add a new group password policy:\n ipa pwpolicy-add --maxlife=90 --minlife=1 --history=10 --minclasses=3 --minlength=8 --priority=10 localadmins\n\n Display the global password policy:\n ipa pwpolicy-show\n\n Display a group password policy:\n ipa pwpolicy-show localadmins\n\n Display the policy that would be applied to a given user:\n ipa pwpolicy-show --user=tuser1\n\n Modify a group password policy:\n ipa pwpolicy-mod --minclasses=2 localadmins\n" ], "previous_source": "", "target": [ "\nПравила паролів\n\nПравила паролів встановлюють обмеження щодо використання паролів IPA,\nзокрема максимальний строк дії, мінімальний строк дії, кількість паролів,\nякі зберігатимуться у журналі, потрібна кількість класів символів (для\nскладних паролів) та мінімальну довжину пароля.\n\nТипово, визначено одні загальні правила для всіх користувачів. Ви можете\nстворити правило паролів, яке стосуватиметься однієї групи. Для одного\nкористувача може бути використано лише один набір правил паролів: груповий\nабо загальний. Групові правила паролів є незалежними, вони не є загальними\nправилами з додаванням нетипових параметрів.\n\nДля кожного набору групових правил паролів має бути встановлено окреме\nзначення пріоритету. Якщо користувач є учасником декількох груп, для яких\nвстановлено правила паролів, пріоритет визначає, які з правил має бути\nзастосовано. Менші значення відповідають вищому пріоритету правил.\n\nГрупові правила паролів автоматично вилучаються під час вилучення\nвідповідних груп.\n\nПРИКЛАДИ:\n\n Внесення змін до загальних правил:\n ipa pwpolicy-mod --minlength=10\n\n Додавання нових групових правил паролів:\n ipa pwpolicy-add --maxlife=90 --minlife=1 --history=10 --minclasses=3 --minlength=8 --priority=10 localadmins\n\n Показ загальних правил паролів:\n ipa pwpolicy-show\n\n Показ групових правил паролів:\n ipa pwpolicy-show localadmins\n\n Показ правил, які має бути застосовано до певного користувача:\n ipa pwpolicy-show --user=tuser1\n\n Внесення змін до групових правил паролів:\n ipa pwpolicy-mod --minclasses=2 localadmins\n" ], "id_hash": 5055512606613454751, "content_hash": 5055512606613454751, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1162, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 206, "source_unit": "https://translate.fedoraproject.org/api/units/2717788/?format=api", "priority": 100, "id": 2734058, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=c628c9ee32b43f9f", "url": "https://translate.fedoraproject.org/api/units/2734058/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.425334Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nPermissions\n" ], "previous_source": "", "target": [ "\nПрава доступу\n" ], "id_hash": -4006266114728824832, "content_hash": -4006266114728824832, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 3886, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 1, "source_unit": "https://translate.fedoraproject.org/api/units/2717790/?format=api", "priority": 100, "id": 2734059, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=4866e231dbe77000", "url": "https://translate.fedoraproject.org/api/units/2734059/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.440710Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nPermissions\n\nA permission enables fine-grained delegation of rights. A permission is\na human-readable form of a 389-ds Access Control Rule, or instruction (ACI).\nA permission grants the right to perform a specific task such as adding a\nuser, modifying a group, etc.\n\nA permission may not contain other permissions.\n\n* A permission grants access to read, write, add or delete.\n* A privilege combines similar permissions (for example all the permissions\n needed to add a user).\n* A role grants a set of privileges to users, groups, hosts or hostgroups.\n\nA permission is made up of a number of different parts:\n\n1. The name of the permission.\n2. The target of the permission.\n3. The rights granted by the permission.\n\nRights define what operations are allowed, and may be one or more\nof the following:\n1. write - write one or more attributes\n2. read - read one or more attributes\n3. add - add a new entry to the tree\n4. delete - delete an existing entry\n5. all - all permissions are granted\n\nRead permission is granted for most attributes by default so the read\npermission is not expected to be used very often.\n\nNote the distinction between attributes and entries. The permissions are\nindependent, so being able to add a user does not mean that the user will\nbe editable.\n\nThere are a number of allowed targets:\n1. type: a type of object (user, group, etc).\n2. memberof: a member of a group or hostgroup\n3. filter: an LDAP filter\n4. subtree: an LDAP filter specifying part of the LDAP DIT. This is a\n super-set of the \"type\" target.\n5. targetgroup: grant access to modify a specific group (such as granting\n the rights to manage group membership)\n\nEXAMPLES:\n\n Add a permission that grants the creation of users:\n ipa permission-add --type=user --permissions=add \"Add Users\"\n\n Add a permission that grants the ability to manage group membership:\n ipa permission-add --attrs=member --permissions=write --type=group \"Manage Group Members\"\n" ], "previous_source": "", "target": [ "\nПрава доступу\n\nЗапис правил доступу уможливлює точне делегування прав. Запис прав доступу\nє зручною для читання обгорткою навколо правила керування доступом 389-ds\nабо інструкції (ACI).\nПраво доступу надає право виконувати специфічне завдання, зокрема додавання\nзапису користувача, внесення зміни до групи тощо.\n\nЗапис прав доступу не може містити інших прав доступу.\n\n* Права доступу надають можливість читати, записувати, вилучати, шукати або\n порівнювати.\n* Привілеї поєднують подібні права доступу (наприклад усі права доступу,\n потрібні для додавання запису користувача).\n* Роль надає набір привілеїв користувачам, групам, вузлам або групам вузлів.\n\nЗапис права доступу складається з декількох різних частин:\n\n1. Назви запису права доступу.\n2. Призначення права доступу.\n3. Права, які надаються записом.\n\nПрава визначають список дій, які можна виконувати. Запис прав може\nбути один або може бути декілька записів з такого набору:\n1. write - запис одного або декількох атрибутів\n2. read - читання одного або декількох атрибутів\n3. search - пошук одного або декількох атрибутів\n4. compare - порівняння одного або декількох атрибутів\n5. add - додавання нового запису до ієрархії\n6. delete - вилучення наявного запису\n7. all - надати усі права доступу\n\nТипово, доступ до читання надається до більшості з атрибутів, отже потреба\nу визначенні прав доступу до читання має виникати доволі нечасто.\n\nЗауважте відмінність між атрибутами і записами. Права доступу є незалежними,\nотже можливість додавання запису користувача не означає, що цей запис згодом\nбуде придатним до редагування.\n\nПередбачено декілька можливих призначень:\n1. type: тип об’єкта (user, group тощо).\n2. memberof: учасник групи або групи вузлів\n3. filter: фільтр LDAP\n4. subtree: фільтр LDAP, що визначає частину DIT LDAP. Є надмножиною\n призначення «type».\n5. targetgroup: надати доступ до зміни вказаної групи (зокрема надати доступ\n до керування участю у групі)\n\nПРИКЛАДИ:\n\n Додати право доступу до створення записів користувачів:\n ipa permission-add --type=user --permissions=add \"Add Users\"\n\n Додати право доступу, яке надає можливість керувати участю у групах:\n ipa permission-add --attrs=member --permissions=write --type=group \"Manage Group Members\"\n" ], "id_hash": -4788718596259920140, "content_hash": -4788718596259920140, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1959, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 325, "source_unit": "https://translate.fedoraproject.org/api/units/2717792/?format=api", "priority": 100, "id": 2734060, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=3d8b0dcef49ec6f4", "url": "https://translate.fedoraproject.org/api/units/2734060/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.452339Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nPermissions\n\nA permission enables fine-grained delegation of rights. A permission is\na human-readable wrapper around a 389-ds Access Control Rule,\nor instruction (ACI).\nA permission grants the right to perform a specific task such as adding a\nuser, modifying a group, etc.\n\nA permission may not contain other permissions.\n\n* A permission grants access to read, write, add, delete, read, search,\n or compare.\n* A privilege combines similar permissions (for example all the permissions\n needed to add a user).\n* A role grants a set of privileges to users, groups, hosts or hostgroups.\n\nA permission is made up of a number of different parts:\n\n1. The name of the permission.\n2. The target of the permission.\n3. The rights granted by the permission.\n\nRights define what operations are allowed, and may be one or more\nof the following:\n1. write - write one or more attributes\n2. read - read one or more attributes\n3. search - search on one or more attributes\n4. compare - compare one or more attributes\n5. add - add a new entry to the tree\n6. delete - delete an existing entry\n7. all - all permissions are granted\n\nNote the distinction between attributes and entries. The permissions are\nindependent, so being able to add a user does not mean that the user will\nbe editable.\n\nThere are a number of allowed targets:\n1. subtree: a DN; the permission applies to the subtree under this DN\n2. target filter: an LDAP filter\n3. target: DN with possible wildcards, specifies entries permission applies to\n\nAdditionally, there are the following convenience options.\nSetting one of these options will set the corresponding attribute(s).\n1. type: a type of object (user, group, etc); sets subtree and target filter.\n2. memberof: apply to members of a group; sets target filter\n3. targetgroup: grant access to modify a specific group (such as granting\n the rights to manage group membership); sets target.\n\nManaged permissions\n\nPermissions that come with IPA by default can be so-called \"managed\"\npermissions. These have a default set of attributes they apply to,\nbut the administrator can add/remove individual attributes to/from the set.\n\nDeleting or renaming a managed permission, as well as changing its target,\nis not allowed.\n\nEXAMPLES:\n\n Add a permission that grants the creation of users:\n ipa permission-add --type=user --permissions=add \"Add Users\"\n\n Add a permission that grants the ability to manage group membership:\n ipa permission-add --attrs=member --permissions=write --type=group \"Manage Group Members\"\n" ], "previous_source": "", "target": [ "\nПрава доступу\n\nЗапис правил доступу уможливлює точне делегування прав. Запис прав доступу\nє зручною для читання обгорткою навколо правила керування доступом 389-ds\nабо інструкції (ACI).\nПраво доступу надає право виконувати специфічне завдання, зокрема додавання\nзапису користувача, внесення зміни до групи тощо.\n\nЗапис прав доступу не може містити інших прав доступу.\n\n* Права доступу надають можливість читати, записувати, вилучати, шукати або\n порівнювати.\n* Привілеї поєднують подібні права доступу (наприклад усі права доступу,\n потрібні для додавання запису користувача).\n* Роль надає набір привілеїв користувачам, групам, вузлам або групам вузлів.\n\nЗапис права доступу складається з декількох різних частин:\n\n1. Назви запису права доступу.\n2. Призначення права доступу.\n3. Права, які надаються записом.\n\nПрава визначають список дій, які можна виконувати. Запис прав може\nбути один або може бути декілька записів з такого набору:\n1. write - запис одного або декількох атрибутів\n2. read - читання одного або декількох атрибутів\n3. search - пошук одного або декількох атрибутів\n4. compare - порівняння одного або декількох атрибутів\n5. add - додавання нового запису до ієрархії\n6. delete - вилучення наявного запису\n7. all - надати усі права доступу\n\nЗауважте відмінність між атрибутами і записами. Права доступу є незалежними,\nотже можливість додавання запису користувача не означає, що цей запис згодом\nбуде придатним до редагування.\n\nПередбачено декілька можливих призначень:\n1. subtree: DN; право доступу застосовується до піддерева DN\n2. target filter: фільтр LDAP\n3. target: DN з можливими символами-замінниками, що визначає записи, яких стосуються права доступу\n\nКрім того, передбачено вказані нижче параметри.\nВстановлення одного з цих параметрів призводить до встановлення відповідних атрибутів.\n1. type: тип об’єкта (користувач, група тощо); встановлює фільтрування за піддеревом (subtree) та фільтрування за призначенням (target filter).\n2. memberof: застосовувати до учасників групи; встановлює фільтр за призначенням (target filter).\n3. targetgroup: надає доступ до внесення змін до певної групи (зокрема, доступ до\n надання можливості керування участю у групі); встановлює призначення (target).\n\nКеровані права доступу\n\nПрава доступу, які типово встановлюються разом з IPA, можуть бути\nтак званими «керованим» правами доступу. Такі права доступу мають\nтиповий набір атрибутів, до яких вони застосовуються. Втім, адміністратор\nможе додавати або вилучати окремі атрибути набору.\n\nВилучення або перейменування керованих прав доступу, а також зміну призначення\nтаких прав, заборонено.\n\nПРИКЛАДИ:\n\n Додати право доступу до створення записів користувачів:\n ipa permission-add --type=user --permissions=add \"Add Users\"\n\n Додати право доступу, яке надає можливість керувати участю у групах:\n ipa permission-add --attrs=member --permissions=write --type=group \"Manage Group Members\"\n" ], "id_hash": 2467052758254385956, "content_hash": 2467052758254385956, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1095, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 405, "source_unit": "https://translate.fedoraproject.org/api/units/2727910/?format=api", "priority": 100, "id": 2734061, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=a23cbb69a1e67b24", "url": "https://translate.fedoraproject.org/api/units/2734061/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.475735Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nPermissions that come with IPA by default can be so-called \"managed\"\npermissions. These have a default set of attributes they apply to,\nbut the administrator can add/remove individual attributes to/from the set.\n" ], "previous_source": "", "target": [ "\nПрава доступу, які типово встановлюються разом з IPA, можуть бути\nтак званими «керованим» правами доступу. Такі права доступу мають\nтиповий набір атрибутів, до яких вони застосовуються. Втім, адміністратор\nможе додавати або вилучати окремі атрибути набору.\n" ], "id_hash": -2425711131919914825, "content_hash": -2425711131919914825, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 3896, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 32, "source_unit": "https://translate.fedoraproject.org/api/units/2717794/?format=api", "priority": 100, "id": 2734062, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=5e562493d633e8b7", "url": "https://translate.fedoraproject.org/api/units/2734062/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.495472Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nPing the remote IPA server to ensure it is running.\n\nThe ping command sends an echo request to an IPA server. The server\nreturns its version information. This is used by an IPA client\nto confirm that the server is available and accepting requests.\n\nThe server from xmlrpc_uri in /etc/ipa/default.conf is contacted first.\nIf it does not respond then the client will contact any servers defined\nby ldap SRV records in DNS.\n\nEXAMPLES:\n\n Ping an IPA server:\n ipa ping\n ------------------------------------------\n IPA server version 2.1.9. API version 2.20\n ------------------------------------------\n\n Ping an IPA server verbosely:\n ipa -v ping\n ipa: INFO: trying https://ipa.example.com/ipa/xml\n ipa: INFO: Forwarding 'ping' to server 'https://ipa.example.com/ipa/xml'\n -----------------------------------------------------\n IPA server version 2.1.9. API version 2.20\n -----------------------------------------------------\n" ], "previous_source": "", "target": [ "\nПеревірка віддаленого сервера IPA з метою переконатися, що він є працездатним.\n\nПрограма ping надсилає луна-запит до сервера IPA. Сервер повертає\nдані щодо його версії. Ці дані використовуються клієнтом IPA\nдля підтвердження, що сервер є доступним і що він приймає запити.\n\nСервер з xmlrpc_uri у /etc/ipa/default.conf перевіряється першим.\nЯкщо він не відповідає, клієнт намагається встановити зв’язок з\nбудь-яким сервером, визначеним записами SRV ldap у DNS.\n\nПРИКЛАДИ:\n\n Перевірити луна-імпульсом сервер IPA:\n ipa ping\n ------------------------------------------\n Сервер IPA версії 2.1.9. Версія API 2.20\n ------------------------------------------\n\n Перевірити луна-імпульсом сервер IPA і отримати докладні дані:\n ipa -v ping\n ipa: INFO: trying https://ipa.example.com/ipa/xml\n ipa: INFO: Forwarding 'ping' to server 'https://ipa.example.com/ipa/xml'\n -----------------------------------------------------\n Сервер IPA версії 2.1.9. Версія API 2.20\n -----------------------------------------------------\n" ], "id_hash": 1720488149672601517, "content_hash": 1720488149672601517, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1137, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 116, "source_unit": "https://translate.fedoraproject.org/api/units/2717796/?format=api", "priority": 100, "id": 2734063, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=97e066db498127ad", "url": "https://translate.fedoraproject.org/api/units/2734063/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.514014Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nPing the remote IPA server to ensure it is running.\n\nThe ping command sends an echo request to an IPA server. The server\nreturns its version information. This is used by an IPA client\nto confirm that the server is available and accepting requests.\n\nThe server from xmlrpc_uri in /etc/ipa/default.conf is contacted first.\nIf it does not respond then the client will contact any servers defined\nby ldap SRV records in DNS.\n\nEXAMPLES:\n\n Ping an IPA server:\n ipa ping\n ------------------------------------------\n IPA server version 2.1.9. API version 2.20\n ------------------------------------------\n\n Ping an IPA server verbosely:\n ipa -v ping\n ipa: INFO: trying https://ipa.example.com/ipa/xml\n ipa: INFO: Forwarding 'ping' to server u'https://ipa.example.com/ipa/xml'\n -----------------------------------------------------\n IPA server version 2.1.9. API version 2.20\n -----------------------------------------------------\n" ], "previous_source": "", "target": [ "\nПеревірка віддаленого сервера IPA з метою переконатися, що він є працездатним.\n\nПрограма ping надсилає луна-запит до сервера IPA. Сервер повертає\nдані щодо його версії. Ці дані використовуються клієнтом IPA\nдля підтвердження, що сервер є доступним і що він приймає запити.\n\nСервер з xmlrpc_uri у /etc/ipa/default.conf перевіряється першим.\nЯкщо він не відповідає, клієнт намагається встановити зв’язок з\nбудь-яким сервером, визначеним записами SRV ldap у DNS.\n\nПРИКЛАДИ:\n\n Перевірити луна-імпульсом сервер IPA:\n ipa ping\n ------------------------------------------\n Сервер IPA версії 2.1.9. Версія API 2.20\n ------------------------------------------\n\n Перевірити луна-імпульсом сервер IPA і отримати докладні дані:\n ipa -v ping\n ipa: INFO: trying https://ipa.example.com/ipa/xml\n ipa: INFO: Forwarding 'ping' to server 'https://ipa.example.com/ipa/xml'\n -----------------------------------------------------\n Сервер IPA версії 2.1.9. Версія API 2.20\n -----------------------------------------------------\n" ], "id_hash": 5087946789067984707, "content_hash": 5087946789067984707, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1968, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 116, "source_unit": "https://translate.fedoraproject.org/api/units/2717798/?format=api", "priority": 100, "id": 2734064, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=c69c04a5c67c8f43", "url": "https://translate.fedoraproject.org/api/units/2734064/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.530119Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nPlugin to make multiple ipa calls via one remote procedure call\n\nTo run this code in the lite-server\n\ncurl -H \"Content-Type:application/json\" -H \"Accept:application/json\" -H \"Accept-Language:en\" --negotiate -u : --cacert /etc/ipa/ca.crt -d @batch_request.json -X POST http://localhost:8888/ipa/json\n\nwhere the contents of the file batch_request.json follow the below example\n\n{\"method\":\"batch\",\"params\":[[\n {\"method\":\"group_find\",\"params\":[[],{}]},\n {\"method\":\"user_find\",\"params\":[[],{\"whoami\":\"true\",\"all\":\"true\"}]},\n {\"method\":\"user_show\",\"params\":[[\"admin\"],{\"all\":true}]}\n ],{}],\"id\":1}\n\nThe format of the response is nested the same way. At the top you will see\n \"error\": null,\n \"id\": 1,\n \"result\": {\n \"count\": 3,\n \"results\": [\n\n\nAnd then a nested response for each IPA command method sent in the request\n" ], "previous_source": "", "target": [ "\nДодаток для виконання декількох викликів ipa за допомогою одного віддаленого виклику процедури\n\nЩоб запустити цей код на легкому сервері, віддайте такі команди:\n\ncurl -H \"Content-Type:application/json\" -H \"Accept:application/json\" -H \"Accept-Language:en\" --negotiate -u : --cacert /etc/ipa/ca.crt -d @batch_request.json -X POST http://localhost:8888/ipa/json\n\nде у файлі batch_request.json міститься десь такий код:\n\n{\"method\":\"batch\",\"params\":[[\n {\"method\":\"group_find\",\"params\":[[],{}]},\n {\"method\":\"user_find\",\"params\":[[],{\"whoami\":\"true\",\"all\":\"true\"}]},\n {\"method\":\"user_show\",\"params\":[[\"admin\"],{\"all\":true}]}\n ],{}],\"id\":1}\n\nФормат відповіді має бути розподілений за рівнями вкладеності у подібний же спосіб. На початку ви побачите таке:\n \"error\": null,\n \"id\": 1,\n \"result\": {\n \"count\": 3,\n \"results\": [\n\n\nа далі буде вкладена відповідь для кожного методу команди IPA, який було надіслано у запиті\n" ], "id_hash": 7922620161662418248, "content_hash": 7922620161662418248, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 379, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 91, "source_unit": "https://translate.fedoraproject.org/api/units/2727915/?format=api", "priority": 100, "id": 2734065, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=edf2cd0faa3c7d48", "url": "https://translate.fedoraproject.org/api/units/2734065/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.545521Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nPlugin to make multiple ipa calls via one remote procedure call\n\nTo run this code in the lite-server\n\ncurl -H \"Content-Type:application/json\" -H \"Accept:application/json\" -H \"Accept-Language:en\" --negotiate -u : --cacert /etc/ipa/ca.crt -d @batch_request.json -X POST http://localhost:8888/ipa/json\n\nwhere the contents of the file batch_request.json follow the below example\n\n{\"method\":\"batch\",\"params\":[[\n {\"method\":\"group_find\",\"params\":[[],{}]},\n {\"method\":\"user_find\",\"params\":[[],{\"whoami\":\"true\",\"all\":\"true\"}]},\n {\"method\":\"user_show\",\"params\":[[\"admin\"],{\"all\":true}]}\n ],{}],\"id\":1}\n\nThe format of the response is nested the same way. At the top you will see\n \"error\": null,\n \"id\": 1,\n \"result\": {\n \"count\": 3,\n \"results\": [\n\n\nAnd then a nested response for each IPA command method sent in the request\n\n" ], "previous_source": "", "target": [ "\nДодаток для виконання декількох викликів ipa за допомогою одного віддаленого виклику процедури\n\nЩоб запустити цей код на легкому сервері, віддайте такі команди:\n\ncurl -H \"Content-Type:application/json\" -H \"Accept:application/json\" -H \"Accept-Language:en\" --negotiate -u : --cacert /etc/ipa/ca.crt -d @batch_request.json -X POST http://localhost:8888/ipa/json\n\nде у файлі batch_request.json міститься десь такий код:\n\n{\"method\":\"batch\",\"params\":[[\n {\"method\":\"group_find\",\"params\":[[],{}]},\n {\"method\":\"user_find\",\"params\":[[],{\"whoami\":\"true\",\"all\":\"true\"}]},\n {\"method\":\"user_show\",\"params\":[[\"admin\"],{\"all\":true}]}\n ],{}],\"id\":1}\n\nФормат відповіді має бути розподілений за рівнями вкладеності у подібний же спосіб. На початку ви побачите таке:\n \"error\": null,\n \"id\": 1,\n \"result\": {\n \"count\": 3,\n \"results\": [\n\n\nа далі буде вкладена відповідь для кожного методу команди IPA, який було надіслано у запиті\n" ], "id_hash": -2604885144289709716, "content_hash": -2604885144289709716, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 4098, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 91, "source_unit": "https://translate.fedoraproject.org/api/units/2727917/?format=api", "priority": 100, "id": 2734066, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=5bd996c335eb716c", "url": "https://translate.fedoraproject.org/api/units/2734066/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.558512Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nPlugins not accessible directly through the CLI, commands used internally\n" ], "previous_source": "", "target": [ "\nІнтерфейс командного рядка не надає безпосереднього доступу до додатків, команди використано для внутрішньої обробки\n" ], "id_hash": 2717175572965292832, "content_hash": 2717175572965292832, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 928, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 10, "source_unit": "https://translate.fedoraproject.org/api/units/2717800/?format=api", "priority": 100, "id": 2734067, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=a5b558c992f6fb20", "url": "https://translate.fedoraproject.org/api/units/2734067/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.574393Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nPrivileges\n\nA privilege combines permissions into a logical task. A permission provides\nthe rights to do a single task. There are some IPA operations that require\nmultiple permissions to succeed. A privilege is where permissions are\ncombined in order to perform a specific task.\n\nFor example, adding a user requires the following permissions:\n * Creating a new user entry\n * Resetting a user password\n * Adding the new user to the default IPA users group\n\nCombining these three low-level tasks into a higher level task in the\nform of a privilege named \"Add User\" makes it easier to manage Roles.\n\nA privilege may not contain other privileges.\n\nSee role and permission for additional information.\n" ], "previous_source": "", "target": [ "\nПривілей\n\nПривілей поєднує права доступу у одне логічне завдання. Право доступу\nнадає можливість виконувати лише одне завдання. У IPA є декілька дій,\nвиконання яких потребує одразу декількох прав доступу. У привілеї такі\nправа доступу поєднуються з метою виконання певної дії.\n\nНаприклад, додавання запису користувача потребує таких прав доступу:\n * право створення запису користувача;\n * право скидання пароля користувача;\n * право додавання користувача до типової групи користувачів IPA.\n\nПоєднання цих трьох низькорівневих завдань у високорівневе завдання у\nформаті привілею з назвою «Add User» полегшує керування ролями.\n\nПривілей не може містити інших привілеїв.\n\nЩоб дізнатися більше, ознайомтеся з довідною щодо ролей та прав доступу.\n" ], "id_hash": -6788250158341464059, "content_hash": -6788250158341464059, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1141, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 114, "source_unit": "https://translate.fedoraproject.org/api/units/2717802/?format=api", "priority": 100, "id": 2734068, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=21cb4a7259916005", "url": "https://translate.fedoraproject.org/api/units/2734068/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.587056Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nProvides API introspection capabilities.\n" ], "previous_source": "", "target": [ "\nНадає можливості інтроспекції програмного інтерфейсу.\n" ], "id_hash": 8811223485751379798, "content_hash": 8811223485751379798, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 2654, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 4, "source_unit": "https://translate.fedoraproject.org/api/units/2722397/?format=api", "priority": 100, "id": 2734069, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=fa47c11390ca4756", "url": "https://translate.fedoraproject.org/api/units/2734069/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.600650Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nRADIUS Proxy Servers\n" ], "previous_source": "", "target": [ "\nПроксі-сервери RADIUS\n" ], "id_hash": -2921000553645543831, "content_hash": -2921000553645543831, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 2547, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 3, "source_unit": "https://translate.fedoraproject.org/api/units/2717804/?format=api", "priority": 100, "id": 2734070, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=57768578fb3cee69", "url": "https://translate.fedoraproject.org/api/units/2734070/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.611178Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nRADIUS Proxy Servers\n\nManage RADIUS Proxy Servers.\n\nIPA supports the use of an external RADIUS proxy server for krb5 OTP\nauthentications. This permits a great deal of flexibility when\nintegrating with third-party authentication services.\n\nEXAMPLES:\n\n Add a new server:\n ipa radiusproxy-add MyRADIUS --server=radius.example.com:1812\n\n Find all servers whose entries include the string \"example.com\":\n ipa radiusproxy-find example.com\n\n Examine the configuration:\n ipa radiusproxy-show MyRADIUS\n\n Change the secret:\n ipa radiusproxy-mod MyRADIUS --secret\n\n Delete a configuration:\n ipa radiusproxy-del MyRADIUS\n" ], "previous_source": "", "target": [ "\nПроксі-сервери RADIUS\n\nКерування проксі-серверами RADIUS.\n\nУ IPA передбачено підтримку зовнішнього проксі-сервера RADIUS для\nвиконання розпізнавання OTP krb5. Це надає системі значної гнучкості\nз метою інтеграції зі сторонніми службами розпізнавання.\n\nПРИКЛАДИ:\n\n Додати новий сервер:\n ipa radiusproxy-add MyRADIUS --server=radius.example.com:1812\n\n Знайти усі сервери, чиї запис містять рядок «example.com»:\n ipa radiusproxy-find example.com\n\n Перевірити налаштування:\n ipa radiusproxy-show MyRADIUS\n\n Змінити реєстраційні дані:\n ipa radiusproxy-mod MyRADIUS --secret\n\n Вилучити налаштування:\n ipa radiusproxy-del MyRADIUS\n" ], "id_hash": -8678263612514546238, "content_hash": -8678263612514546238, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1191, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 74, "source_unit": "https://translate.fedoraproject.org/api/units/2722400/?format=api", "priority": 100, "id": 2734071, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=07909d394cdf4dc2", "url": "https://translate.fedoraproject.org/api/units/2734071/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.621321Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nRE-ENROLLMENT:\n\nHost that has been enrolled at some point, and lost its configuration (e.g. VM\ndestroyed) can be re-enrolled.\n\nFor more information, consult the manual pages for ipa-client-install.\n\nA host can optionally store information such as where it is located,\nthe OS that it runs, etc.\n" ], "previous_source": "", "target": [ "\nПОВТОРНА РЕЄСТРАЦІЯ:\n\nВузол, якому вже колись було надано певну роль, але налаштування було втрачено\n(наприклад через знищення віртуальної машини), можна знову зареєструвати (надати роль).\n\nЩоб дізнатися більше, зверніться до сторінок підручника (man) щодо ipa-client-install.\n\nЗапис вузла може, якщо потрібно, зберігати відомості щодо розташування, запущеної\nопераційної системи тощо.\n" ], "id_hash": -4248529155225925200, "content_hash": -4248529155225925200, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 2296, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 46, "source_unit": "https://translate.fedoraproject.org/api/units/2717806/?format=api", "priority": 100, "id": 2734072, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=450a313e34de49b0", "url": "https://translate.fedoraproject.org/api/units/2734072/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.631793Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nRaise the IPA Domain Level.\n" ], "previous_source": "", "target": [ "\nПідняти рівень домену IPA.\n" ], "id_hash": 6101079848955994096, "content_hash": 6101079848955994096, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1638, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 5, "source_unit": "https://translate.fedoraproject.org/api/units/2714985/?format=api", "priority": 100, "id": 2734073, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=d4ab63cc3750dff0", "url": "https://translate.fedoraproject.org/api/units/2734073/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.644647Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nRealm domains\n\nManage the list of domains associated with IPA realm.\n\nEXAMPLES:\n\n Display the current list of realm domains:\n ipa realmdomains-show\n\n Replace the list of realm domains:\n ipa realmdomains-mod --domain=example.com\n ipa realmdomains-mod --domain={example1.com,example2.com,example3.com}\n\n Add a domain to the list of realm domains:\n ipa realmdomains-mod --add-domain=newdomain.com\n\n Delete a domain from the list of realm domains:\n ipa realmdomains-mod --del-domain=olddomain.com\n" ], "previous_source": "", "target": [ "\nДомени області\n\nКерування списком доменів, пов’язаних з областю IPA.\n\nПРИКЛАДИ:\n\n Показати поточний список доменів області:\n ipa realmdomains-show\n\n Замірити список доменів області:\n ipa realmdomains-mod --domain=example.com\n ipa realmdomains-mod --domain={example1.com,example2.com,example3.com}\n\n Додати домен до списку доменів області:\n ipa realmdomains-mod --add-domain=newdomain.com\n\n Вилучити домен зі списку доменів області:\n ipa realmdomains-mod --del-domain=olddomain.com\n" ], "id_hash": 8805162111605521468, "content_hash": 8805162111605521468, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1210, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 57, "source_unit": "https://translate.fedoraproject.org/api/units/2722404/?format=api", "priority": 100, "id": 2734074, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=fa323849ebf9bc3c", "url": "https://translate.fedoraproject.org/api/units/2734074/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.657928Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nRealm domains\n\nManage the list of domains associated with IPA realm.\n\nThis list is useful for Domain Controllers from other realms which have\nestablished trust with this IPA realm. They need the information to know\nwhich request should be forwarded to KDC of this IPA realm.\n\nAutomatic management: a domain is automatically added to the realm domains\nlist when a new DNS Zone managed by IPA is created. Same applies for deletion.\n\nExternally managed DNS: domains which are not managed in IPA server DNS\nneed to be manually added to the list using ipa realmdomains-mod command.\n\nEXAMPLES:\n\n Display the current list of realm domains:\n ipa realmdomains-show\n\n Replace the list of realm domains:\n ipa realmdomains-mod --domain=example.com\n ipa realmdomains-mod --domain={example1.com,example2.com,example3.com}\n\n Add a domain to the list of realm domains:\n ipa realmdomains-mod --add-domain=newdomain.com\n\n Delete a domain from the list of realm domains:\n ipa realmdomains-mod --del-domain=olddomain.com\n" ], "previous_source": "", "target": [ "\nДомени області\n\nКерування списком доменів, пов’язаних з областю IPA.\n\nЦей список є корисним для контролерів доменів з інших областей, які\nмають встановити відносини довіри із цією областю IPA. Цим контролерам\nпотрібні дані щодо того, які запити слід переспрямовувати до KDC цієї\nобласті IPA.\n\nАвтоматичне керування: домен автоматично додається до списку доменів\nобласті, коли створюється нова зона DNS, керована IPA. Те саме стосується\nвилучення.\n\nКерована ззовні DNS: домени, які не керуються у DNS сервера IPA, має бути\nвручну додано до списку за допомогою команди ipa realmdomains-mod.\n\nПРИКЛАДИ:\n\n Показати поточний список доменів області:\n ipa realmdomains-show\n\n Замірити список доменів області:\n ipa realmdomains-mod --domain=example.com\n ipa realmdomains-mod --domain={example1.com,example2.com,example3.com}\n\n Додати домен до списку доменів області:\n ipa realmdomains-mod --add-domain=newdomain.com\n\n Вилучити домен зі списку доменів області:\n ipa realmdomains-mod --del-domain=olddomain.com\n" ], "id_hash": 6411842767686316390, "content_hash": 6411842767686316390, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 2456, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 142, "source_unit": "https://translate.fedoraproject.org/api/units/2717808/?format=api", "priority": 100, "id": 2734075, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=d8fb71069b99b166", "url": "https://translate.fedoraproject.org/api/units/2734075/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.671201Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nRemoval of '%(hostname)s' leads to disconnected topology in suffix '%(suffix)s':\n%(errors)s" ], "previous_source": "", "target": [ "\nВилучення запису «%(hostname)s» призведе до нез’єднаної топології у суфіксу «%(suffix)s»:\n%(errors)s" ], "id_hash": 227743931767923622, "content_hash": 227743931767923622, "location": "", "context": "", "note": "", "flags": "python-format", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 4624, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 11, "source_unit": "https://translate.fedoraproject.org/api/units/2717810/?format=api", "priority": 100, "id": 2734076, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=83291be638c723a6", "url": "https://translate.fedoraproject.org/api/units/2734076/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.694398Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nReplication topology in suffix '%(suffix)s' is disconnected:\n%(errors)s" ], "previous_source": "", "target": [ "\nТопологія реплікації у суфіксі «%(suffix)s» є нез’єднаною:\n%(errors)s" ], "id_hash": -6748975459154231913, "content_hash": -6748975459154231913, "location": "", "context": "", "note": "", "flags": "python-format", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 4623, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 8, "source_unit": "https://translate.fedoraproject.org/api/units/2717812/?format=api", "priority": 100, "id": 2734077, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=2256d293d7487d97", "url": "https://translate.fedoraproject.org/api/units/2734077/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.707395Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nReturn information about currently authenticated identity\n\nWho am I command returns information on how to get\nmore details about the identity authenticated for this\nrequest. The information includes:\n\n * type of object\n * command to retrieve details of the object\n * arguments and options to pass to the command\n\nThe information is returned as a dictionary. Examples below use\n'key: value' output for illustrative purposes.\n\nEXAMPLES:\n\n Look up as IPA user:\n kinit admin\n ipa console\n >> api.Command.whoami()\n ------------------------------------------\n object: user\n command: user_show/1\n arguments: admin\n ------------------------------------------\n\n Look up as a user from a trusted domain:\n kinit user@AD.DOMAIN\n ipa console\n >> api.Command.whoami()\n ------------------------------------------\n object: idoverrideuser\n command: idoverrideuser_show/1\n arguments: ('default trust view', 'user@ad.domain')\n ------------------------------------------\n\n Look up as a host:\n kinit -k\n ipa console\n >> api.Command.whoami()\n ------------------------------------------\n object: host\n command: host_show/1\n arguments: ipa.example.com\n ------------------------------------------\n\n Look up as a Kerberos service:\n kinit -k -t /path/to/keytab HTTP/ipa.example.com\n ipa console\n >> api.Command.whoami()\n ------------------------------------------\n object: service\n command: service_show/1\n arguments: HTTP/ipa.example.com\n ------------------------------------------\n" ], "previous_source": "", "target": [ "\nПовернути дані щодо поточного розпізнаного профілю\n\nКоманда визначення профілю повертає дані щодо того, як\nотримати більше даних про профіль, розпізнаний для\nцього запиту. Дані:\n\n * тип об’єкта\n * команда для отримання подробиць щодо об’єкта\n * аргументи та параметри, які слід передати команді\n\nДані повертаються у форматі словника. Нижче, як приклад,\nнаведено виведення у форматі «ключ: значення».\n\nПриклади:\n\n Пошук від імені користувача IPA:\n kinit admin\n ipa console\n >> api.Command.whoami()\n ------------------------------------------\n object: user\n command: user_show/1\n arguments: admin\n ------------------------------------------\n\n Пошук від імені користувача довіреного домену:\n kinit user@AD.DOMAIN\n ipa console\n >> api.Command.whoami()\n ------------------------------------------\n object: idoverrideuser\n command: idoverrideuser_show/1\n arguments: ('default trust view', 'user@ad.domain')\n ------------------------------------------\n\n Пошук від імені вузла:\n kinit -k\n ipa console\n >> api.Command.whoami()\n ------------------------------------------\n object: host\n command: host_show/1\n arguments: ipa.example.com\n ------------------------------------------\n\n Пошук від імені служби Kerberos:\n kinit -k -t /path/to/keytab HTTP/ipa.example.com\n ipa console\n >> api.Command.whoami()\n ------------------------------------------\n object: service\n command: service_show/1\n arguments: HTTP/ipa.example.com\n ------------------------------------------\n" ], "id_hash": 1904881040652490793, "content_hash": 1904881040652490793, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 2800, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 153, "source_unit": "https://translate.fedoraproject.org/api/units/2717814/?format=api", "priority": 100, "id": 2734078, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=9a6f7f36c777d829", "url": "https://translate.fedoraproject.org/api/units/2734078/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.723653Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nRights define what operations are allowed, and may be one or more\nof the following:\n1. write - write one or more attributes\n2. read - read one or more attributes\n3. search - search on one or more attributes\n4. compare - compare one or more attributes\n5. add - add a new entry to the tree\n6. delete - delete an existing entry\n7. all - all permissions are granted\n" ], "previous_source": "", "target": [ "\nПрава визначають список дій, які можна виконувати. Запис прав може\nбути один або може бути декілька записів з такого набору:\n1. write - запис одного або декількох атрибутів\n2. read - читання одного або декількох атрибутів\n3. search - пошук одного або декількох атрибутів\n4. compare - порівняння одного або декількох атрибутів\n5. add - додавання нового запису до ієрархії\n6. delete - вилучення наявного запису\n7. all - надати усі права доступу\n" ], "id_hash": 3027857269661852623, "content_hash": 3027857269661852623, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 3891, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 72, "source_unit": "https://translate.fedoraproject.org/api/units/2717816/?format=api", "priority": 100, "id": 2734079, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=aa051c24fcc763cf", "url": "https://translate.fedoraproject.org/api/units/2734079/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.743162Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nRoles\n\nA role is used for fine-grained delegation. A permission grants the ability\nto perform given low-level tasks (add a user, modify a group, etc.). A\nprivilege combines one or more permissions into a higher-level abstraction\nsuch as useradmin. A useradmin would be able to add, delete and modify users.\n\nPrivileges are assigned to Roles.\n\nUsers, groups, hosts and hostgroups may be members of a Role.\n\nRoles can not contain other roles.\n\nEXAMPLES:\n\n Add a new role:\n ipa role-add --desc=\"Junior-level admin\" junioradmin\n\n Add some privileges to this role:\n ipa role-add-privilege --privileges=addusers junioradmin\n ipa role-add-privilege --privileges=change_password junioradmin\n ipa role-add-privilege --privileges=add_user_to_default_group junioradmin\n\n Add a group of users to this role:\n ipa group-add --desc=\"User admins\" useradmins\n ipa role-add-member --groups=useradmins junioradmin\n\n Display information about a role:\n ipa role-show junioradmin\n\n The result of this is that any users in the group 'junioradmin' can\n add users, reset passwords or add a user to the default IPA user group.\n" ], "previous_source": "", "target": [ "\nРолі\n\nРоль використовується для уточнення налаштування прав доступу. Право доступу\nнадає можливість виконувати деякі низькорівневі завдання (додавання запису\nкористувача, внесення змін до групи тощо). Привілей поєднують одне або декілька\nправ доступу у високорівневу абстракцію, наприклад «адміністратор користувачів»\n(useradmin). Такий useradmin зможе додавати, вилучати і вносити зміни до записів\nкористувачів.\n\nПривілеї пов’язуються з ролями.\n\nУчасниками ролі можуть бути користувачі, групи, вузли та групи вузлів.\n\nРолі можуть містити інші ролі.\n\nПРИКЛАДИ:\n\n Додавання нової ролі:\n ipa role-add --desc=\"Junior-level admin\" junioradmin\n\n Додавання привілеїв до цієї ролі:\n ipa role-add-privilege --privileges=addusers junioradmin\n ipa role-add-privilege --privileges=change_password junioradmin\n ipa role-add-privilege --privileges=add_user_to_default_group junioradmin\n\n Додавання користувачів до цієї ролі:\n ipa group-add --desc=\"User admins\" useradmins\n ipa role-add-member --groups=useradmins junioradmin\n\n Показ даних щодо ролі:\n ipa role-show junioradmin\n\n Результатом виконання команд буде те, що всі користувачі групи «useradmins»\n зможуть додавати записи користувачів, скидати паролі або додавати користувача\n до типової групи користувачів IPA.\n" ], "id_hash": 4301174780384733327, "content_hash": 4301174780384733327, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1217, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 152, "source_unit": "https://translate.fedoraproject.org/api/units/2722409/?format=api", "priority": 100, "id": 2734080, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=bbb0d7ac95b3688f", "url": "https://translate.fedoraproject.org/api/units/2734080/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.763446Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nRoutines for constructing certificate signing requests using IPA data and\nstored templates.\n" ], "previous_source": "", "target": [ "\nПроцедури для побудови запитів щодо підписування сертифікатів за допомогою даних IPA та\nзбережених шаблонів.\n" ], "id_hash": 8371975924546677059, "content_hash": 8371975924546677059, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 2001, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 12, "source_unit": "https://translate.fedoraproject.org/api/units/2727933/?format=api", "priority": 100, "id": 2734081, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=f42f3bbf2aba2943", "url": "https://translate.fedoraproject.org/api/units/2734081/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.781708Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nSEARCHING:\n" ], "previous_source": "", "target": [ "\nПОШУК:\n" ], "id_hash": -4186152959537249879, "content_hash": -4186152959537249879, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 4363, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 1, "source_unit": "https://translate.fedoraproject.org/api/units/2717818/?format=api", "priority": 100, "id": 2734082, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=45e7cc0fff5501a9", "url": "https://translate.fedoraproject.org/api/units/2734082/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.800774Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nSELinux User Mapping\n\nMap IPA users to SELinux users by host.\n\nHosts, hostgroups, users and groups can be either defined within\nthe rule or it may point to an existing HBAC rule. When using\n--hbacrule option to selinuxusermap-find an exact match is made on the\nHBAC rule name, so only one or zero entries will be returned.\n\nEXAMPLES:\n\n Create a rule, \"test1\", that sets all users to xguest_u:s0 on the host \"server\":\n ipa selinuxusermap-add --usercat=all --selinuxuser=xguest_u:s0 test1\n ipa selinuxusermap-add-host --hosts=server.example.com test1\n\n Create a rule, \"test2\", that sets all users to guest_u:s0 and uses an existing HBAC rule for users and hosts:\n ipa selinuxusermap-add --usercat=all --hbacrule=webserver --selinuxuser=guest_u:s0 test2\n\n Display the properties of a rule:\n ipa selinuxusermap-show test2\n\n Create a rule for a specific user. This sets the SELinux context for\n user john to unconfined_u:s0-s0:c0.c1023 on any machine:\n ipa selinuxusermap-add --hostcat=all --selinuxuser=unconfined_u:s0-s0:c0.c1023 john_unconfined\n ipa selinuxusermap-add-user --users=john john_unconfined\n\n Disable a rule:\n ipa selinuxusermap-disable test1\n\n Enable a rule:\n ipa selinuxusermap-enable test1\n\n Find a rule referencing a specific HBAC rule:\n ipa selinuxusermap-find --hbacrule=allow_some\n\n Remove a rule:\n ipa selinuxusermap-del john_unconfined\n\nSEEALSO:\n\n The list controlling the order in which the SELinux user map is applied\n and the default SELinux user are available in the config-show command.\n" ], "previous_source": "", "target": [ "\nВстановлення відповідності користувачів SELinux\n\nВстановити відповідність користувачів IPA користувачам SELinux за вузлами.\n\nВузли, групи вузлів, користувачі і групи можна визначати або\nв межах правила, або може вказувати на вже створене правило HBAC.\nУ разі використання параметра --hbacrule команди selinuxusermap-find\nбуде встановлено точну відповідність за назвою правила HBAC, отже буде\nповернуто один або жодного запису.\n\nПРИКЛАДИ:\n\n Створення правила, «test1», яке встановлює всіх користувачів у xguest_u:s0 на вузлі «server»:\n ipa selinuxusermap-add --usercat=all --selinuxuser=xguest_u:s0 test1\n ipa selinuxusermap-add-host --hosts=serverexample.com test1\n\n Створення правила, \"test2\", яке встановлює всіх користувачів у guest_u:s0 і використовує вже створене правило HBAC для користувачів і вузлів:\n ipa selinuxusermap-add --usercat=all --hbacrule=webserver --selinuxuser=guest_u:s0 test2\n\n Показ властивостей правил:\n ipa selinuxusermap-show test2\n\n Створення правила для певного користувача. Встановлює контекст SELinux для користувача\n john у unconfined_u:s0-s0:c0.c1023 на всіх комп’ютерах:\n ipa selinuxusermap-add --hostcat=all --selinuxuser=unconfined_u:s0-s0:c0.c1023 john_unconfined\n ipa selinuxusermap-add-user --users=john john_unconfined\n\n Вимикання правила:\n ipa selinuxusermap-disable test1\n\n Увімкнення правила:\n ipa selinuxusermap-enable test1\n\n Пошук правила, що посилається на певне правило HBAC:\n ipa selinuxusermap-find --hbacrule=allow_some\n\n Вилучення правила:\n ipa selinuxusermap-del john_unconfined\n\nТАКОЖ ОЗНАЙОМТЕСЯ:\n\n Застосовується список, який визначає порядок, у якому встановлюється\n відповідність користувачів. Типового користувача можна за допомогою\n програми config-show.\n" ], "id_hash": 2098558445426861959, "content_hash": 2098558445426861959, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1249, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 199, "source_unit": "https://translate.fedoraproject.org/api/units/2717820/?format=api", "priority": 100, "id": 2734083, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=9d1f93c998106787", "url": "https://translate.fedoraproject.org/api/units/2734083/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.813046Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nSUPPORTED ZONE TYPES\n\n * Master zone (dnszone-*), contains authoritative data.\n * Forward zone (dnsforwardzone-*), forwards queries to configured forwarders\n (a set of DNS servers).\n" ], "previous_source": "", "target": [ "\nПІДТРИМУВАНІ ТИПИ ЗОН\n\n * Основна зона (dnszone-*), містить довірені дані.\n * Зона переспрямовування (dnsforwardzone-*), переспрямовує запити до налаштованих засобів обробки\n (набору серверів DNS).\n" ], "id_hash": 8360069128499449546, "content_hash": 8360069128499449546, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 4167, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 24, "source_unit": "https://translate.fedoraproject.org/api/units/2717822/?format=api", "priority": 100, "id": 2734084, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=f404ee942deb4eca", "url": "https://translate.fedoraproject.org/api/units/2734084/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.830365Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nSearch for ACIs.\n\n Returns a list of ACIs\n\n EXAMPLES:\n\n To find all ACIs that apply directly to members of the group ipausers:\n ipa aci-find --memberof=ipausers\n\n To find all ACIs that grant add access:\n ipa aci-find --permissions=add\n\n Note that the find command only looks for the given text in the set of\n ACIs, it does not evaluate the ACIs to see if something would apply.\n For example, searching on memberof=ipausers will find all ACIs that\n have ipausers as a memberof. There may be other ACIs that apply to\n members of that group indirectly.\n " ], "previous_source": "", "target": [ "\nПошук ACI.\n\n Повертає список ACI\n\n ПРИКЛАДИ:\n\n Знайти усі ACI, які застосовуються безпосередньо до учасників групи ipausers:\n ipa aci-find --memberof=ipausers\n\n Знайти усі ACI, які надають доступ add:\n ipa aci-find --permissions=add\n\n Зауважте, що команда пошуку виконує пошук вказаного тексту лише у\n наборі ACI, а не визначає, чи буде застосовано щось у ACI.\n Наприклад, у результаті пошуку memberof=ipausers буде знайдено усі ACI,\n у яких memberof містить ipausers. Але можуть існувати інші ACI, які\n застосовуються до учасників цієї групи опосередковано.\n " ], "id_hash": -558403035710723672, "content_hash": -558403035710723672, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 323, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 92, "source_unit": "https://translate.fedoraproject.org/api/units/2717824/?format=api", "priority": 100, "id": 2734085, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=78402765c6f669a8", "url": "https://translate.fedoraproject.org/api/units/2734085/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.843534Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nSelf-service Permissions\n\nA permission enables fine-grained delegation of permissions. Access Control\nRules, or instructions (ACIs), grant permission to permissions to perform\ngiven tasks such as adding a user, modifying a group, etc.\n\nA Self-service permission defines what an object can change in its own entry.\n\n\nEXAMPLES:\n\n Add a self-service rule to allow users to manage their address (using Bash\n brace expansion):\n ipa selfservice-add --permissions=write --attrs={street,postalCode,l,c,st} \"Users manage their own address\"\n\n When managing the list of attributes you need to include all attributes\n in the list, including existing ones.\n Add telephoneNumber to the list (using Bash brace expansion):\n ipa selfservice-mod --attrs={street,postalCode,l,c,st,telephoneNumber} \"Users manage their own address\"\n\n Display our updated rule:\n ipa selfservice-show \"Users manage their own address\"\n\n Delete a rule:\n ipa selfservice-del \"Users manage their own address\"\n" ], "previous_source": "", "target": [ "\nПрава доступу самообслуговування\n\nПрава доступу надають змогу точно налаштувати уповноваження. За допомогою\nправил керування доступом та інструкцій (ACI) надаються права доступу до\nвиконання вказаних завдань, зокрема додавання записів користувачів,\nвнесення змін до записів груп тощо.\n\nПрава доступу самообслуговування визначають права об’єкта на внесення змін\nдо власного запису.\n\n\nПРИКЛАДИ:\n\n Додавання правила самообслуговування для уможливлення керування користувачами\n власною адресою (з використанням виразу Bash у фігурних дужках):\n ipa selfservice-add --permissions=write --attrs={street,postalCode,l,c,st} \"Users manage their own address\"\n\n Якщо ви керуєте списком атрибутів, вам слід включити до списку всі атрибути,\n зокрема вже створені. Додавання telephoneNumber до списку (з використанням виразу Bash у фігурних дужках):\n ipa selfservice-mod --attrs={street,postalCode,l,c,st,telephoneNumber} \"Users manage their own address\"\n\n Показ нашого оновленого правила:\n ipa selfservice-show \"Users manage their own address\"\n\n Вилучення правила:\n ipa selfservice-del \"Users manage their own address\"\n" ], "id_hash": 4236915357238379565, "content_hash": 4236915357238379565, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1241, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 126, "source_unit": "https://translate.fedoraproject.org/api/units/2717826/?format=api", "priority": 100, "id": 2734086, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=bacc8c11bb97442d", "url": "https://translate.fedoraproject.org/api/units/2734086/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.858109Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nSelf-service Permissions\n\nA permission enables fine-grained delegation of permissions. Access Control\nRules, or instructions (ACIs), grant permission to permissions to perform\ngiven tasks such as adding a user, modifying a group, etc.\n\nA Self-service permission defines what an object can change in its own entry.\n\n\nEXAMPLES:\n\n Add a self-service rule to allow users to manage their address:\n ipa selfservice-add --permissions=write --attrs=street,postalCode,l,c,st \"Users manage their own address\"\n\n When managing the list of attributes you need to include all attributes\n in the list, including existing ones. Add telephoneNumber to the list:\n ipa selfservice-mod --attrs=street,postalCode,l,c,st,telephoneNumber \"Users manage their own address\"\n\n Display our updated rule:\n ipa selfservice-show \"Users manage their own address\"\n\n Delete a rule:\n ipa selfservice-del \"Users manage their own address\"\n" ], "previous_source": "", "target": [ "\nПрава доступу самообслуговування\n\nПрава доступу надають змогу точно налаштувати уповноваження. За допомогою\nправил керування доступом та інструкцій (ACI) надаються права доступу до\nвиконання вказаних завдань, зокрема додавання записів користувачів,\nвнесення змін до записів груп тощо.\n\nПрава доступу самообслуговування визначають права об’єкта на внесення змін\nдо власного запису.\n\n\nПРИКЛАДИ:\n\n Додавання правила самообслуговування для уможливлення керування користувачами\n власною адресою:\n ipa selfservice-add --permissions=write --attrs=street,postalCode,l,c,st \"Users manage their own address\"\n\n Якщо ви керуєте списком атрибутів, вам слід включити до списку всі атрибути,\n зокрема вже створені. Додавання telephoneNumber до списку:\n ipa selfservice-mod --attrs=street,postalCode,l,c,st,telephoneNumber \"Users manage their own address\"\n\n Показ нашого оновленого правила:\n ipa selfservice-show \"Users manage their own address\"\n\n Вилучення правила:\n ipa selfservice-del \"Users manage their own address\"\n" ], "id_hash": -130140641994351122, "content_hash": -130140641994351122, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1973, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 118, "source_unit": "https://translate.fedoraproject.org/api/units/2717828/?format=api", "priority": 100, "id": 2734087, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=7e31a5c68f15ddee", "url": "https://translate.fedoraproject.org/api/units/2734087/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.877095Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nServer configuration\n\nManage the default values that IPA uses and some of its tuning parameters.\n\nNOTES:\n\nThe password notification value (--pwdexpnotify) is stored here so it will\nbe replicated. It is not currently used to notify users in advance of an\nexpiring password.\n\nSome attributes are read-only, provided only for information purposes. These\ninclude:\n\nCertificate Subject base: the configured certificate subject base,\n e.g. O=EXAMPLE.COM. This is configurable only at install time.\nPassword plug-in features: currently defines additional hashes that the\n password will generate (there may be other conditions).\n\nWhen setting the order list for mapping SELinux users you may need to\nquote the value so it isn't interpreted by the shell.\n\nEXAMPLES:\n\n Show basic server configuration:\n ipa config-show\n\n Show all configuration options:\n ipa config-show --all\n\n Change maximum username length to 99 characters:\n ipa config-mod --maxusername=99\n\n Increase default time and size limits for maximum IPA server search:\n ipa config-mod --searchtimelimit=10 --searchrecordslimit=2000\n\n Set default user e-mail domain:\n ipa config-mod --emaildomain=example.com\n\n Enable migration mode to make \"ipa migrate-ds\" command operational:\n ipa config-mod --enable-migration=TRUE\n\n Define SELinux user map order:\n ipa config-mod --ipaselinuxusermaporder='guest_u:s0$xguest_u:s0$user_u:s0-s0:c0.c1023$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023'\n" ], "previous_source": "", "target": [ "\nНалаштування сервера\n\nКерування типовими значеннями, які використовує IPA, та деякими з\nпридатних до зміни параметрів.\n\nЗАУВАЖЕННЯ:\n\nТут зберігається значення параметра сповіщення щодо паролів\n(--pwdexpnotify), отже його не буде скопійовано. Це значення поки що\nне використовується для сповіщення користувачів щодо завершення строку дії\nпароля.\n\nДеякі з атрибутів придатні лише для читання, їх буде показано лише з метою\nінформування. Серед цих атрибутів:\n\nОснова призначення сертифіката: змінна основа призначення сертифіката,\n наприклад O=EXAMPLE.COM. Цей атрибут можна налаштувати лише під час\n встановлення.\nПараметри додатка роботи з паролями: у поточній версії визначають додаткові\n хеші, які створюються на основі пароля (можуть бути і інші умови).\n\nПід час встановлення списку пріоритетності для користувачів SELinux може виникнути\nпотреба у додаванні лапок до значення, щоб оболонка не обробляла параметр.\n\nПРИКЛАДИ:\n\n Показати основні налаштування сервера:\n ipa config-show\n\n Показати всі параметри налаштування:\n ipa config-show --all\n\n Змінити максимальну довжину імені користувача на 99 символів:\n ipa config-mod --maxusername=99\n\n Збільшити типовий час і максимальне обмеження на розмір пошуку\n сервера IPA:\n ipa config-mod --searchtimelimit=10 --searchrecordslimit=2000\n\n Встановити типовий домен електронної пошти користувачів:\n ipa config-mod --emaildomain=example.com\n\n Увімкнути режим перенесення, щоб зробити команду \"ipa migrate-ds\"\n працездатною:\n ipa config-mod --enable-migration=TRUE\n\n Визначити пріоритетність користувачів у карті SELinux:\n ipa config-mod --ipaselinuxusermaporder='guest_u:s0$xguest_u:s0$user_u:s0-s0:c0.c1023$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023'\n" ], "id_hash": 5044435619049702186, "content_hash": 5044435619049702186, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 381, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 178, "source_unit": "https://translate.fedoraproject.org/api/units/2722414/?format=api", "priority": 100, "id": 2734088, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=c6016f780dc9032a", "url": "https://translate.fedoraproject.org/api/units/2734088/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.891814Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nServer configuration\n\nManage the default values that IPA uses and some of its tuning parameters.\n\nNOTES:\n\nThe password notification value (--pwdexpnotify) is stored here so it will\nbe replicated. It is not currently used to notify users in advance of an\nexpiring password.\n\nSome attributes are read-only, provided only for information purposes. These\ninclude:\n\nCertificate Subject base: the configured certificate subject base,\n e.g. O=EXAMPLE.COM. This is configurable only at install time.\nPassword plug-in features: currently defines additional hashes that the\n password will generate (there may be other conditions).\n\nWhen setting the order list for mapping SELinux users you may need to\nquote the value so it isn't interpreted by the shell.\n\nThe maximum length of a hostname in Linux is controlled by\nMAXHOSTNAMELEN in the kernel and defaults to 64. Some other operating\nsystems, Solaris for example, allows hostnames up to 255 characters.\nThis option will allow flexibility in length but by default limiting\nto the Linux maximum length.\n\nEXAMPLES:\n\n Show basic server configuration:\n ipa config-show\n\n Show all configuration options:\n ipa config-show --all\n\n Change maximum username length to 99 characters:\n ipa config-mod --maxusername=99\n\n Change maximum host name length to 255 characters:\n ipa config-mod --maxhostname=255\n\n Increase default time and size limits for maximum IPA server search:\n ipa config-mod --searchtimelimit=10 --searchrecordslimit=2000\n\n Set default user e-mail domain:\n ipa config-mod --emaildomain=example.com\n\n Enable migration mode to make \"ipa migrate-ds\" command operational:\n ipa config-mod --enable-migration=TRUE\n\n Define SELinux user map order:\n ipa config-mod --ipaselinuxusermaporder='guest_u:s0$xguest_u:s0$user_u:s0-s0:c0.c1023$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023'\n" ], "previous_source": "", "target": [ "\nНалаштування сервера\n\nКерування типовими значеннями, які використовує IPA, та деякими з\nпридатних до зміни параметрів.\n\nЗАУВАЖЕННЯ:\n\nТут зберігається значення параметра сповіщення щодо паролів\n(--pwdexpnotify), отже його не буде скопійовано. Це значення поки що\nне використовується для сповіщення користувачів щодо завершення строку дії\nпароля.\n\nДеякі з атрибутів придатні лише для читання, їх буде показано лише з метою\nінформування. Серед цих атрибутів:\n\nОснова призначення сертифіката: змінна основа призначення сертифіката,\n наприклад O=EXAMPLE.COM. Цей атрибут можна налаштувати лише під час\n встановлення.\nПараметри додатка роботи з паролями: у поточній версії визначають додаткові\n хеші, які створюються на основі пароля (можуть бути і інші умови).\n\nПід час встановлення списку пріоритетності для користувачів SELinux може виникнути\nпотреба у додаванні лапок до значення, щоб оболонка не обробляла параметр.\n\nМаксимальна довжина назви вузла у Linux керується значенням\nMAXHOSTNAMELEN у ядрі. Типовим значенням є 64. У деяких інших\nопераційних системах, наприклад у Solaris, можна використовувати у\nназвах до 255 символів. Цей параметр надає гнучкості щодо довжини, але\nу Linux його значення все одно обмежено максимальним можливим.\n\nПРИКЛАДИ:\n\n Показати основні налаштування сервера:\n ipa config-show\n\n Показати всі параметри налаштування:\n ipa config-show --all\n\n Змінити максимальну довжину імені користувача на 99 символів:\n ipa config-mod --maxusername=99\n\n Змінити максимальну довжину назви вузла на 255 символів:\n ipa config-mod --maxhostname=255\n\nЗбільшити типовий час і максимальне обмеження на розмір пошуку\n сервера IPA:\n ipa config-mod --searchtimelimit=10 --searchrecordslimit=2000\n\n Встановити типовий домен електронної пошти користувачів:\n ipa config-mod --emaildomain=example.com\n\n Увімкнути режим перенесення, щоб зробити команду \"ipa migrate-ds\"\n працездатною:\n ipa config-mod --enable-migration=TRUE\n\n Визначити пріоритетність користувачів у карті SELinux:\n ipa config-mod --ipaselinuxusermaporder='guest_u:s0$xguest_u:s0$user_u:s0-s0:c0.c1023$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023'\n" ], "id_hash": -8659160863174770583, "content_hash": -8659160863174770583, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 2815, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 237, "source_unit": "https://translate.fedoraproject.org/api/units/2727942/?format=api", "priority": 100, "id": 2734089, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=07d47b12b980c069", "url": "https://translate.fedoraproject.org/api/units/2734089/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.907797Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nService Constrained Delegation\n\nManage rules to allow constrained delegation of credentials so\nthat a service can impersonate a user when communicating with another\nservice without requiring the user to actually forward their TGT.\nThis makes for a much better method of delegating credentials as it\nprevents exposure of the short term secret of the user.\n\nThe naming convention is to append the word \"target\" or \"targets\" to\na matching rule name. This is not mandatory but helps conceptually\nto associate rules and targets.\n\nA rule consists of two things:\n - A list of targets the rule applies to\n - A list of memberPrincipals that are allowed to delegate for\n those targets\n\nA target consists of a list of principals that can be delegated.\n\nIn English, a rule says that this principal can delegate as this\nlist of principals, as defined by these targets.\n\nEXAMPLES:\n\n Add a new constrained delegation rule:\n ipa servicedelegationrule-add ftp-delegation\n\n Add a new constrained delegation target:\n ipa servicedelegationtarget-add ftp-delegation-target\n\n Add a principal to the rule:\n ipa servicedelegationrule-add-member --principals=ftp/ipa.example.com ftp-delegation\n\n Add our target to the rule:\n ipa servicedelegationrule-add-target --servicedelegationtargets=ftp-delegation-target ftp-delegation\n\n Add a principal to the target:\n ipa servicedelegationtarget-add-member --principals=ldap/ipa.example.com ftp-delegation-target\n\n Display information about a named delegation rule and target:\n ipa servicedelegationrule_show ftp-delegation\n ipa servicedelegationtarget_show ftp-delegation-target\n\n Remove a constrained delegation:\n ipa servicedelegationrule-del ftp-delegation-target\n ipa servicedelegationtarget-del ftp-delegation\n\nIn this example the ftp service can get a TGT for the ldap service on\nthe bound user's behalf.\n\nIt is strongly discouraged to modify the delegations that ship with\nIPA, ipa-http-delegation and its targets ipa-cifs-delegation-targets and\nipa-ldap-delegation-targets. Incorrect changes can remove the ability\nto delegate, causing the framework to stop functioning.\n" ], "previous_source": "", "target": [ "\nОбмежене службами делегування\n\nКерування правилами, за допомогою яких можна обмежити делегування\nреєстраційних даних так, що служба зможе виконувати персоніфікацію\nкористувача під час обміну даними з іншою службою без потреби для\nкористувача насправді переспрямовувати квиток для отримання квитка\n(TGT). Так створюється значно кращий метод делегування реєстраційних\nданих, оскільки він запобігає розкриттю короткотермінових ключів\nдоступу користувачів.\n\nВідповідно до угоди з іменування, до назви правила додається слово\n\"target\" або \"targets\". Така схема назв не є обов’язковою, але вона\nдопомагає концептуально пов’язати правила та їхні призначення.\n\nПравило складається з двох компонентів:\n - Списку цілей (призначень), яких стосується правило\n - Списку memberPrincipals, яким дозволено делегування для\n цих цілей\n\nЗапис цілі складається зі списку реєстраційних записів, які можна\nделегувати.\n\nЯкщо простіше, правило стверджує, що певний реєстраційний запис\nможна делегувати як вказаний список реєстраційних записів,\nвідповідно до визначеного списку цілей.\n\nПРИКЛАДИ:\n\n Додати нове правило обмеженого делегування:\n ipa servicedelegationrule-add ftp-delegation\n\n Додати нову ціль обмеженого делегування:\n ipa servicedelegationtarget-add ftp-delegation-target\n\n Додати реєстраційний запис до правила:\n ipa servicedelegationrule-add-member --principals=ftp/ipa.example.com ftp-delegation\n\n Додати нашу ціль до правила:\n ipa servicedelegationrule-add-target --servicedelegationtargets=ftp-delegation-target ftp-delegation\n\n Додати реєстраційний запис до цілі:\n ipa servicedelegationtarget-add-member --principals=ldap/ipa.example.com ftp-delegation-target\n\n Показати дані щодо іменованого правила і цілі:\n ipa servicedelegationrule_show ftp-delegation\n ipa servicedelegationtarget_show ftp-delegation-target\n\n Вилучити обмежене делегування:\n ipa servicedelegationrule-del ftp-delegation-target\n ipa servicedelegationtarget-del ftp-delegation\n\nУ цьому прикладі служба ftp може отримувати квиток для отримання квитка для\nслужби ldap від імені пов’язаного користувача.\n\nМи наполегливо не рекомендуємо змінювати делегування, які постачаються з\nIPA, ipa-http-delegation та його цілі ipa-cifs-delegation-targets і\nipa-ldap-delegation-targets. Некоректні зміни можуть усунути можливість\nделегування, що спричинить непрацездатність усієї системи.\n" ], "id_hash": -4827466967722214768, "content_hash": -4827466967722214768, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1670, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 269, "source_unit": "https://translate.fedoraproject.org/api/units/2722416/?format=api", "priority": 100, "id": 2734090, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=3d01645eaffc3a90", "url": "https://translate.fedoraproject.org/api/units/2734090/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.929948Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nServices\n\nA IPA service represents a service that runs on a host. The IPA service\nrecord can store a Kerberos principal, an SSL certificate, or both.\n\nAn IPA service can be managed directly from a machine, provided that\nmachine has been given the correct permission. This is true even for\nmachines other than the one the service is associated with. For example,\nrequesting an SSL certificate using the host service principal credentials\nof the host. To manage a service using host credentials you need to\nkinit as the host:\n\n # kinit -kt /etc/krb5.keytab host/ipa.example.com@EXAMPLE.COM\n\nAdding an IPA service allows the associated service to request an SSL\ncertificate or keytab, but this is performed as a separate step; they\nare not produced as a result of adding the service.\n\nOnly the public aspect of a certificate is stored in a service record;\nthe private key is not stored.\n\nEXAMPLES:\n\n Add a new IPA service:\n ipa service-add HTTP/web.example.com\n\n Allow a host to manage an IPA service certificate:\n ipa service-add-host --hosts=web.example.com HTTP/web.example.com\n ipa role-add-member --hosts=web.example.com certadmin\n\n Override a default list of supported PAC types for the service:\n ipa service-mod HTTP/web.example.com --pac-type=MS-PAC\n\n A typical use case where overriding the PAC type is needed is NFS.\n Currently the related code in the Linux kernel can only handle Kerberos\n tickets up to a maximal size. Since the PAC data can become quite large it\n is recommended to set --pac-type=NONE for NFS services.\n\n Delete an IPA service:\n ipa service-del HTTP/web.example.com\n\n Find all IPA services associated with a host:\n ipa service-find web.example.com\n\n Find all HTTP services:\n ipa service-find HTTP\n\n Disable the service Kerberos key and SSL certificate:\n ipa service-disable HTTP/web.example.com\n\n Request a certificate for an IPA service:\n ipa cert-request --principal=HTTP/web.example.com example.csr\n" ], "previous_source": "", "target": [ "\nСлужби\n\nСлужба IPA — це служба, що працює на вузлі системи. У записі служби\nIPA можуть зберігатися дані реєстраційного запису Kerberos, сертифікат\nSSL або обидва набори даних.\n\nСлужбою IPA можна керувати безпосередньо з комп’ютера, якщо системі\nцього комп’ютера надано достатні права доступу. Це стосується навіть\nкомп’ютерів, відмінних від тих, з якими пов’язано службу. Наприклад,\nвони можуть надсилати запит щодо сертифіката SSL за допомогою\nреєстраційних даних служби вузла. Для керування службою за допомогою\nреєстраційних даних вузла слід віддати команду ініціалізації kinit\nвід імені вузла:\n\n # kinit -kt /etc/krb5.keytab host/ipa.example.com@EXAMPLE.COM\n\nДодавання служби IPA надає доступ пов’язаній службі до надсилання\nзапитів щодо сертифікатів SSL та таблиці ключів, але створення самих\nзапитів є окремим кроком: відповідні дані не створюються у результаті\nпростого додавання служби.\n\nУ записі служби зберігаються лише відкриті дані сертифіката; закритий\nключ не зберігається.\n\nПРИКЛАДИ:\n\n Додати нову службу IPA:\n ipa service-add HTTP/web.example.com\n\n Дозволити вузлу керувати сертифікатом служби IPA:\n ipa service-add-host --hosts=web.example.com HTTP/web.example.com\n ipa role-add-member --hosts=web.example.com certadmin\n\n Перевизначити типовий список підтримуваних типів PAC для служби:\n ipa service-mod HTTP/web.example.com --pac-type=MS-PAC\n\n Типовим випадком, коли потрібне перевизначення типу PAC є NFS.\n У поточній версії ядра Linux відповідний код може працювати лише з\n квитками Kerberos, розмір яких не перевищує максимально заданого.\n Оскільки дані PAC можуть бути доволі об’ємними, для служб NFS\n рекомендуємо встановити --pac-type=NONE.\n\n Вилучити службу IPA:\n ipa service-del HTTP/web.example.com\n\n Знайти усіх служби IPA, пов’язані із вузлом:\n ipa service-find web.example.com\n\n Знайти усі служби HTTP:\n ipa service-find HTTP\n\n Вимкнути службу ключів Kerberos і сертифіката SSL:\n ipa service-disable HTTP/web.example.com\n\n Надіслати запит щодо сертифіката для служби IPA:\n ipa cert-request --principal=HTTP/web.example.com example.csr\n" ], "id_hash": 705357416508783590, "content_hash": 705357416508783590, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 2466, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 283, "source_unit": "https://translate.fedoraproject.org/api/units/2717830/?format=api", "priority": 100, "id": 2734091, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=89c9eed54ab17be6", "url": "https://translate.fedoraproject.org/api/units/2734091/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.951493Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nServices\n\nA IPA service represents a service that runs on a host. The IPA service\nrecord can store a Kerberos principal, an SSL certificate, or both.\n\nAn IPA service can be managed directly from a machine, provided that\nmachine has been given the correct permission. This is true even for\nmachines other than the one the service is associated with. For example,\nrequesting an SSL certificate using the host service principal credentials\nof the host. To manage a service using host credentials you need to\nkinit as the host:\n\n # kinit -kt /etc/krb5.keytab host/ipa.example.com@EXAMPLE.COM\n\nAdding an IPA service allows the associated service to request an SSL\ncertificate or keytab, but this is performed as a separate step; they\nare not produced as a result of adding the service.\n\nOnly the public aspect of a certificate is stored in a service record;\nthe private key is not stored.\n\nEXAMPLES:\n\n Add a new IPA service:\n ipa service-add HTTP/web.example.com\n\n Allow a host to manage an IPA service certificate:\n ipa service-add-host --hosts=web.example.com HTTP/web.example.com\n ipa role-add-member --hosts=web.example.com certadmin\n\n Override a default list of supported PAC types for the service:\n ipa service-mod HTTP/web.example.com --pac-type=MS-PAC\n\n A typical use case where overriding the PAC type is needed is NFS.\n Currently the related code in the Linux kernel can only handle Kerberos\n tickets up to a maximal size. Since the PAC data can become quite large it\n is recommended to set --pac-type=NONE for NFS services.\n\n Delete an IPA service:\n ipa service-del HTTP/web.example.com\n\n Find all IPA services associated with a host:\n ipa service-find web.example.com\n\n Find all HTTP services:\n ipa service-find HTTP\n\n Disable the service Kerberos key and SSL certificate:\n ipa service-disable HTTP/web.example.com\n\n Request a certificate for an IPA service:\n ipa cert-request --principal=HTTP/web.example.com example.csr\n\n Allow user to create a keytab:\n ipa service-allow-create-keytab HTTP/web.example.com --users=tuser1\n\n Generate and retrieve a keytab for an IPA service:\n ipa-getkeytab -s ipa.example.com -p HTTP/web.example.com -k /etc/httpd/httpd.keytab\n" ], "previous_source": "", "target": [ "\nСлужби\n\nСлужба IPA — це служба, що працює на вузлі системи. У записі служби\nIPA можуть зберігатися дані реєстраційного запису Kerberos, сертифікат\nSSL або обидва набори даних.\n\nСлужбою IPA можна керувати безпосередньо з комп’ютера, якщо системі\nцього комп’ютера надано достатні права доступу. Це стосується навіть\nкомп’ютерів, відмінних від тих, з якими пов’язано службу. Наприклад,\nвони можуть надсилати запит щодо сертифіката SSL за допомогою\nреєстраційних даних служби вузла. Для керування службою за допомогою\nреєстраційних даних вузла слід віддати команду ініціалізації kinit\nвід імені вузла:\n\n # kinit -kt /etc/krb5.keytab host/ipa.example.com@EXAMPLE.COM\n\nДодавання служби IPA надає доступ пов’язаній службі до надсилання\nзапитів щодо сертифікатів SSL та таблиці ключів, але створення самих\nзапитів є окремим кроком: відповідні дані не створюються у результаті\nпростого додавання служби.\n\nУ записі служби зберігаються лише відкриті дані сертифіката; закритий\nключ не зберігається.\n\nПРИКЛАДИ:\n\n Додати нову службу IPA:\n ipa service-add HTTP/web.example.com\n\n Дозволити вузлу керувати сертифікатом служби IPA:\n ipa service-add-host --hosts=web.example.com HTTP/web.example.com\n ipa role-add-member --hosts=web.example.com certadmin\n\n Перевизначити типовий список підтримуваних типів PAC для служби:\n ipa service-mod HTTP/web.example.com --pac-type=MS-PAC\n\n Типовим випадком, коли потрібне перевизначення типу PAC є NFS.\n У поточній версії ядра Linux відповідний код може працювати лише з\n квитками Kerberos, розмір яких не перевищує максимально заданого.\n Оскільки дані PAC можуть бути доволі об’ємними, для служб NFS\n рекомендуємо встановити --pac-type=NONE.\n\n Вилучити службу IPA:\n ipa service-del HTTP/web.example.com\n\n Знайти усіх служби IPA, пов’язані із вузлом:\n ipa service-find web.example.com\n\n Знайти усі служби HTTP:\n ipa service-find HTTP\n\n Вимкнути службу ключів Kerberos і сертифіката SSL:\n ipa service-disable HTTP/web.example.com\n\n Надіслати запит щодо сертифіката для служби IPA:\n ipa cert-request --principal=HTTP/web.example.com example.csr\n\n Дозволити користувачеві створювати сховище ключів:\n ipa service-allow-create-keytab HTTP/web.example.com --users=tuser1\n\n Створити і отримати вміст сховища ключів для служби IPA:\n ipa-getkeytab -s ipa.example.com -p HTTP/web.example.com -k /etc/httpd/httpd.keytab\n" ], "id_hash": -8256542117714809751, "content_hash": -8256542117714809751, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1264, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 309, "source_unit": "https://translate.fedoraproject.org/api/units/2727946/?format=api", "priority": 100, "id": 2734092, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=0d6adeb0608eac69", "url": "https://translate.fedoraproject.org/api/units/2734092/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.970932Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nServices\n\nA IPA service represents a service that runs on a host. The IPA service\nrecord can store a Kerberos principal, an SSL certificate, or both.\n\nAn IPA service can be managed directly from a machine, provided that\nmachine has been given the correct permission. This is true even for\nmachines other than the one the service is associated with. For example,\nrequesting an SSL certificate using the host service principal credentials\nof the host. To manage a service using host credentials you need to\nkinit as the host:\n\n # kinit -kt /etc/krb5.keytab host/ipa.example.com@EXAMPLE.COM\n\nAdding an IPA service allows the associated service to request an SSL\ncertificate or keytab, but this is performed as a separate step; they\nare not produced as a result of adding the service.\n\nOnly the public aspect of a certificate is stored in a service record;\nthe private key is not stored.\n\nEXAMPLES:\n\n Add a new IPA service:\n ipa service-add HTTP/web.example.com\n\n Allow a host to manage an IPA service certificate:\n ipa service-add-host --hosts=web.example.com HTTP/web.example.com\n ipa role-add-member --hosts=web.example.com certadmin\n\n Override a default list of supported PAC types for the service:\n ipa service-mod HTTP/web.example.com --pac-type=MS-PAC\n\n Delete an IPA service:\n ipa service-del HTTP/web.example.com\n\n Find all IPA services associated with a host:\n ipa service-find web.example.com\n\n Find all HTTP services:\n ipa service-find HTTP\n\n Disable the service Kerberos key and SSL certificate:\n ipa service-disable HTTP/web.example.com\n\n Request a certificate for an IPA service:\n ipa cert-request --principal=HTTP/web.example.com example.csr\n\n Generate and retrieve a keytab for an IPA service:\n ipa-getkeytab -s ipa.example.com -p HTTP/web.example.com -k /etc/httpd/httpd.keytab\n" ], "previous_source": "", "target": [ "\nСлужби\n\nСлужба IPA — це служба, що працює на вузлі системи. У записі служби\nIPA можуть зберігатися дані реєстраційного запису Kerberos, сертифікат\nSSL або обидва набори даних.\n\nСлужбою IPA можна керувати безпосередньо з комп’ютера, якщо системі\nцього комп’ютера надано достатні права доступу. Це стосується навіть\nкомп’ютерів, відмінних від тих, з якими пов’язано службу. Наприклад,\nвони можуть надсилати запит щодо сертифіката SSL за допомогою\nреєстраційних даних служби вузла. Для керування службою за допомогою\nреєстраційних даних вузла слід віддати команду ініціалізації kinit\nвід імені вузла:\n\n # kinit -kt /etc/krb5.keytab host/ipa.example.com@EXAMPLE.COM\n\nДодавання служби IPA надає доступ пов’язаній службі до надсилання\nзапитів щодо сертифікатів SSL та таблиці ключів, але створення самих\nзапитів є окремим кроком: відповідні дані не створюються у результаті\nпростого додавання служби.\n\nУ записі служби зберігаються лише відкриті дані сертифіката; закритий\nключ не зберігається.\n\nПРИКЛАДИ:\n\n Додати нову службу IPA:\n ipa service-add HTTP/web.example.com\n\n Дозволити вузлу керувати сертифікатом служби IPA:\n ipa service-add-host --hosts=web.example.com HTTP/web.example.com\n ipa role-add-member --hosts=web.example.com certadmin\n\n Перевизначити типовий список підтримуваних типів PAC для служби:\n ipa service-mod HTTP/web.example.com --pac-type=MS-PAC\n\n Вилучити службу IPA:\n ipa service-del HTTP/web.example.com\n\n Знайти усіх служби IPA, пов’язані із вузлом:\n ipa service-find web.example.com\n\n Знайти усі служби HTTP:\n ipa service-find HTTP\n\n Вимкнути службу ключів Kerberos і сертифіката SSL:\n ipa service-disable HTTP/web.example.com\n\n Надіслати запит щодо сертифіката для служби IPA:\n ipa cert-request --principal=HTTP/web.example.com example.csr\n\n Створити і отримати вміст сховища ключів для служби IPA:\n ipa-getkeytab -s ipa.example.com -p HTTP/web.example.com -k /etc/httpd/httpd.keytab\n" ], "id_hash": -8249761538065651413, "content_hash": -8249761538065651413, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1974, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 251, "source_unit": "https://translate.fedoraproject.org/api/units/2717832/?format=api", "priority": 100, "id": 2734093, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=0d82f59719eaa92b", "url": "https://translate.fedoraproject.org/api/units/2734093/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:26.993309Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nSession Support for IPA\n" ], "previous_source": "", "target": [ "\nПідтримка сеансів для IPA\n" ], "id_hash": -3203048986140429516, "content_hash": -3203048986140429516, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 2736, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 4, "source_unit": "https://translate.fedoraproject.org/api/units/2727949/?format=api", "priority": 100, "id": 2734094, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=538c7beae6ecb334", "url": "https://translate.fedoraproject.org/api/units/2734094/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:27.015151Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nSession Support for IPA\nJohn Dennis <jdennis@redhat.com>\n\nGoals\n=====\n\nProvide per-user session data caching which persists between\nrequests. Desired features are:\n\n* Integrates cleanly with minimum impact on existing infrastructure.\n\n* Provides maximum security balanced against real-world performance\n demands.\n\n* Sessions must be able to be revoked (flushed).\n\n* Should be flexible and easy to use for developers.\n\n* Should leverage existing technology and code to the maximum extent\n possible to avoid re-invention, excessive implementation time and to\n benefit from robustness in field proven components commonly shared\n in the open source community.\n\n* Must support multiple independent processes which share session\n data.\n\n* System must function correctly if session data is available or not.\n\n* Must be high performance.\n\n* Should not be tied to specific web servers or browsers. Should\n integrate with our chosen WSGI model.\n\nIssues\n======\n\nCookies\n-------\n\nMost session implementations are based on the use of cookies. Cookies\nhave some inherent problems.\n\n* User has the option to disable cookies.\n\n* User stored cookie data is not secure. Can be mitigated by setting\n flags indicating the cookie is only to be used with SSL secured HTTP\n connections to specific web resources and setting the cookie to\n expire at session termination. Most modern browsers enforce these.\n\nWhere to store session data?\n----------------------------\n\nSession data may be stored on either on the client or on the\nserver. Storing session data on the client addresses the problem of\nsession data availability when requests are serviced by independent web\nservers because the session data travels with the request. However\nthere are data size limitations. Storing session data on the client\nalso exposes sensitive data but this can be mitigated by encrypting\nthe session data such that only the server can decrypt it.\n\nThe more conventional approach is to bind session data to a unique\nname, the session ID. The session ID is transmitted to the client and\nthe session data is paired with the session ID on the server in a\nassociative data store. The session data is retrieved by the server\nusing the session ID when the receiving the request. This eliminates\nexposing sensitive session data on the client along with limitations\non data size. It however introduces the issue of session data\navailability when requests are serviced by more than one server\nprocess.\n\nMulti-process session data availability\n---------------------------------------\n\nApache (and other web servers) fork child processes to handle requests\nin parallel. Also web servers may be deployed in a farm where requests\nare load balanced in round robin fashion across different nodes. In\nboth cases session data cannot be stored in the memory of a server\nprocess because it is not available to other processes, either sibling\nchildren of a master server process or server processes on distinct\nnodes.\n\nTypically this is addressed by storing session data in a SQL\ndatabase. When a request is received by a server process containing a\nsession ID in it's cookie data the session ID is used to perform a SQL\nquery and the resulting data is then attached to the request as it\nproceeds through the request processing pipeline. This of course\nintroduces coherency issues.\n\nFor IPA the introduction of a SQL database dependency is undesired and\nshould be avoided.\n\nSession data may also be shared by independent processes by storing\nthe session data in files.\n\nAn alternative solution which has gained considerable popularity\nrecently is the use of a fast memory based caching server. Data is\nstored in a single process memory and may be queried and set via a\nlight weight protocol using standard socket mechanisms, memcached is\none example. A typical use is to optimize SQL queries by storing a SQL\nresult in shared memory cache avoiding the more expensive SQL\noperation. But the memory cache has distinct advantages in non-SQL\nsituations as well.\n\nPossible implementations for use by IPA\n=======================================\n\nApache Sessions\n---------------\n\nApache has 2.3 has implemented session support via these modules:\n\n mod_session\n Overarching session support based on cookies.\n\n See: http://httpd.apache.org/docs/2.3/mod/mod_session.html\n\n mod_session_cookie\n Stores session data in the client.\n\n See: http://httpd.apache.org/docs/2.3/mod/mod_session_cookie.html\n\n mod_session_crypto\n Encrypts session data for security. Encryption key is shared\n configuration parameter visible to all Apache processes and is\n stored in a configuration file.\n\n See: http://httpd.apache.org/docs/2.3/mod/mod_session_crypto.html\n\n mod_session_dbd\n Stores session data in a SQL database permitting multiple\n processes to access and share the same session data.\n\n See: http://httpd.apache.org/docs/2.3/mod/mod_session_dbd.html\n\nIssues with Apache sessions\n~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nAlthough Apache has implemented generic session support and Apache is\nour web server of preference it nonetheless introduces issues for IPA.\n\n * Session support is only available in httpd >= 2.3 which at the\n time of this writing is currently only available as a Beta release\n from upstream. We currently only ship httpd 2.2, the same is true\n for other distributions.\n\n * We could package and ship the sessions modules as a temporary\n package in httpd 2.2 environments. But this has the following\n consequences:\n\n - The code has to be backported. the module API has changed\n slightly between httpd 2.2 and 2.3. The backporting is not\n terribly difficult and a proof of concept has been\n implemented.\n\n - We would then be on the hook to package and maintain a special\n case Apache package. This is maintenance burden as well as a\n distribution packaging burden. Both of which would be best\n avoided if possible.\n\n * The design of the Apache session modules is such that they can\n only be manipulated by other Apache modules. The ability of\n consumers of the session data to control the session data is\n simplistic, constrained and static during the period the request\n is processed. Request handlers which are not native Apache modules\n (e.g. IPA via WSGI) can only examine the session data\n via request headers and reset it in response headers.\n\n * Shared session data is available exclusively via SQL.\n\nHowever using the 2.3 Apache session modules would give us robust\nsession support implemented in C based on standardized Apache\ninterfaces which are widely used.\n\nPython Web Frameworks\n---------------------\n\nVirtually every Python web framework supports cookie based sessions,\ne.g. Django, Twisted, Zope, Turbogears etc. Early on in IPA we decided\nto avoid the use of these frameworks. Trying to pull in just one part\nof these frameworks just to get session support would be problematic\nbecause the code does not function outside it's framework.\n\nIPA implemented sessions\n------------------------\n\nOriginally it was believed the path of least effort was to utilize\nexisting session support, most likely what would be provided by\nApache. However there are enough basic modular components available in\nnative Python and other standard packages it should be possible to\nprovide session support meeting the aforementioned goals with a modest\nimplementation effort. Because we're leveraging existing components\nthe implementation difficulties are subsumed by other components which\nhave already been field proven and have community support. This is a\nsmart strategy.\n\nProposed Solution\n=================\n\nOur interface to the web server is via WSGI which invokes a callback\nper request passing us an environmental context for the request. For\nthis discussion we'll name the WSGI callback \"application()\", a\nconventional name in WSGI parlance.\n\nShared session data will be handled by memcached. We will create one\ninstance of memcached on each server node dedicated to IPA\nexclusively. Communication with memcached will be via a UNIX socket\nlocated in the file system under /var/run/ipa_memcached. It will be\nprotected by file permissions and optionally SELinux policy.\n\nIn application() we examine the request cookies and if there is an IPA\nsession cookie with a session ID we retrieve the session data from our\nmemcached instance.\n\nThe session data will be a Python dict. IPA components will read or\nwrite their session information by using a pre-agreed upon name\n(e.g. key) in the dict. This is a very flexible system and consistent\nwith how we pass data in most parts of IPA.\n\nIf the session data is not available an empty session data dict will\nbe created.\n\nHow does this session data travel with the request in the IPA\npipeline? In IPA we use the HTTP request/response to implement RPC. In\napplication() we convert the request into a procedure call passing it\narguments derived from the HTTP request. The passed parameters are\nspecific to the RPC method being invoked. The context the RPC call is\nexecuting in is not passed as an RPC parameter.\n\nHow would the contextual information such as session data be bound to\nthe request and hence the RPC call?\n\nIn IPA when a RPC invocation is being prepared from a request we\nrecognize this will only ever be processed serially by one Python\nthread. A thread local dict called \"context\" is allocated for each\nthread. The context dict is cleared in between requests (e.g. RPC method\ninvocations). The per-thread context dict is populated during the\nlifetime of the request and is used as a global data structure unique to\nthe request that various IPA component can read from and write to with\nthe assurance the data is unique to the current request and/or method\ncall.\n\nThe session data dict will be written into the context dict under the\nsession key before the RPC method begins execution. Thus session data\ncan be read and written by any IPA component by accessing\n``context.session``.\n\nWhen the RPC method finishes execution the session data bound to the\nrequest/method is retrieved from the context and written back to the\nmemcached instance. The session ID is set in the response sent back to\nthe client in the ``Set-Cookie`` header along with the flags\ncontrolling it's usage.\n\nIssues and details\n------------------\n\nIPA code cannot depend on session data being present, however it\nshould always update session data with the hope it will be available\nin the future. Session data may not be available because:\n\n * This is the first request from the user and no session data has\n been created yet.\n\n * The user may have cookies disabled.\n\n * The session data may have been flushed. memcached operates with\n a fixed memory allocation and will flush entries on a LRU basis,\n like with any cache there is no guarantee of persistence.\n\n Also we may have have deliberately expired or deleted session\n data, see below.\n\nCookie manipulation is done via the standard Python Cookie module.\n\nSession cookies will be set to only persist as long as the browser has\nthe session open. They will be tagged so the browser only returns\nthe session ID on SSL secured HTTP requests. They will not be visible\nto Javascript in the browser.\n\nSession ID's will be created by using 48 bits of random data and\nconverted to 12 hexadecimal digits. Newly generated session ID's will\nbe checked for prior existence to handle the unlikely case the random\nnumber repeats.\n\nmemcached will have significantly higher performance than a SQL or file\nbased storage solution. Communication is effectively though a pipe\n(UNIX socket) using a very simple protocol and the data is held\nentirely in process memory. memcached also scales easily, it is easy\nto add more memcached processes and distribute the load across them.\nAt this point in time we don't anticipate the need for this.\n\nA very nice feature of the Python memcached module is that when a data\nitem is written to the cache it is done with standard Python pickling\n(pickling is a standard Python mechanism to marshal and unmarshal\nPython objects). We adopt the convention the object written to cache\nwill be a dict to meet our internal data handling conventions. The\npickling code will recursively handle nested objects in the dict. Thus\nwe gain a lot of flexibility using standard Python data structures to\nstore and retrieve our session data without having to author and debug\ncode to marshal and unmarshal the data if some other storage mechanism\nhad been used. This is a significant implementation win. Of course\nsome common sense limitations need to observed when deciding on what\nis written to the session cache keeping in mind the data is shared\nbetween processes and it should not be excessively large (a\nconfigurable option)\n\nWe can set an expiration on memcached entries. We may elect to do that\nto force session data to be refreshed periodically. For example we may\nwish the client to present fresh credentials on a periodic basis even\nif the cached credentials are otherwise within their validity period.\n\nWe can explicitly delete session data if for some reason we believe it\nis stale, invalid or compromised.\n\nmemcached also gives us certain facilities to prevent race conditions\nbetween different processes utilizing the cache. For example you can\ncheck of the entry has been modified since you last read it or use CAS\n(Check And Set) semantics. What has to be protected in terms of cache\ncoherency will likely have to be determined as the session support is\nutilized and different data items are added to the cache. This is very\nmuch data and context specific. Fortunately memcached operations are\natomic.\n\nControlling the memcached process\n---------------------------------\n\nWe need a mechanism to start the memcached process and secure it so\nthat only IPA components can access it.\n\nAlthough memcached ships with both an initscript and systemd unit\nfiles those are for generic instances. We want a memcached instance\ndedicated exclusively to IPA usage. To accomplish this we would install\na systemd unit file or an SysV initscript to control the IPA specific\nmemcached service. ipactl would be extended to know about this\nadditional service. systemd's cgroup facility would give us additional\nmechanisms to integrate the IPA memcached service within a larger IPA\nprocess group.\n\nProtecting the memcached data would be done via file permissions (and\noptionally SELinux policy) on the UNIX domain socket. Although recent\nimplementations of memcached support authentication via SASL this\nintroduces a performance and complexity burden not warranted when\ncached is dedicated to our exclusive use and access controlled by OS\nmechanisms.\n\nConventionally daemons are protected by assigning a system uid and/or\ngid to the daemon. A daemon launched by root will drop it's privileges\nby assuming the effective uid:gid assigned to it. File system access\nis controlled by the OS via the effective identity and SELinux policy\ncan be crafted based on the identity. Thus the memcached UNIX socket\nwould be protected by having it owned by a specific system user and/or\nmembership in a restricted system group (discounting for the moment\nSELinux).\n\nUnfortunately we currently do not have an IPA system uid whose\nidentity our processes operate under nor do we have an IPA system\ngroup. IPA does manage a collection of related processes (daemons) and\nhistorically each has been assigned their own uid. When these\nunrelated processes communicate they mutually authenticate via other\nmechanisms. We do not have much of a history of using shared file\nsystem objects across identities. When file objects are created they\nare typically assigned the identity of daemon needing to access the\nobject and are not accessed by other daemons, or they carry root\nidentity.\n\nWhen our WSGI application runs in Apache it is run as a WSGI\ndaemon. This means when Apache starts up it forks off WSGI processes\nfor us and we are independent of other Apache processes. When WSGI is\nrun in this mode there is the ability to set the uid:gid of the WSGI\nprocess hosting us, however we currently do not take advantage of this\noption. WSGI can be run in other modes as well, only in daemon mode\ncan the uid:gid be independently set from the rest of Apache. All\nprocesses started by Apache can be set to a common uid:gid specified\nin the global Apache configuration, by default it's\napache:apache. Thus when our IPA code executes it is running as\napache:apache.\n\nTo protect our memcached UNIX socket we can do one of two things:\n\n1. Assign it's uid:gid as apache:apache. This would limit access to\n our cache only to processes running under httpd. It's somewhat\n restricted but far from ideal. Any code running in the web server\n could potentially access our cache. It's difficult to control what the\n web server runs and admins may not understand the consequences of\n configuring httpd to serve other things besides IPA.\n\n2. Create an IPA specific uid:gid, for example ipa:ipa. We then configure\n our WSGI application to run as the ipa:ipa user and group. We also\n configure our memcached instance to run as the ipa:ipa user and\n group. In this configuration we are now fully protected, only our WSGI\n code can read & write to our memcached UNIX socket.\n\nHowever there may be unforeseen issues by converting our code to run as\nsomething other than apache:apache. This would require some\ninvestigation and testing.\n\nIPA is dependent on other system daemons, specifically Directory\nServer (ds) and Certificate Server (cs). Currently we configure ds to\nrun under the dirsrv:dirsrv user and group, an identity of our\ncreation. We allow cs to default to it's pkiuser:pkiuser user and\ngroup. Should these other cooperating daemons also run under the\ncommon ipa:ipa user and group identities? At first blush there would\nseem to be an advantage to coalescing all process identities under a\ncommon IPA user and group identity. However these other processes do\nnot depend on user and group permissions when working with external\nagents, processes, etc. Rather they are designed to be stand-alone\nnetwork services which authenticate their clients via other\nmechanisms. They do depend on user and group permission to manage\ntheir own file system objects. If somehow the ipa user and/or group\nwere compromised or malicious code somehow executed under the ipa\nidentity there would be an advantage in having the cooperating\nprocesses cordoned off under their own identities providing one extra\nlayer of protection. (Note, these cooperating daemons may not even be\nco-located on the same node in which case the issue is moot)\n\nThe UNIX socket behavior (ldapi) with Directory Server is as follows:\n\n * The socket ownership is: root:root\n\n * The socket permissions are: 0666\n\n * When connecting via ldapi you must authenticate as you would\n normally with a TCP socket, except ...\n\n * If autobind is enabled and the uid:gid is available via\n SO_PEERCRED and the uid:gid can be found in the set of users known\n to the Directory Server then that connection will be bound as that\n user.\n\n * Otherwise an anonymous bind will occur.\n\nmemcached UNIX socket behavior is as follows:\n\n * memcached can be invoked with a user argument, no group may be\n specified. The effective uid is the uid of the user argument and\n the effective gid is the primary group of the user, let's call\n this euid:egid\n\n * The socket ownership is: euid:egid\n\n * The socket permissions are 0700 by default, but this can be\n modified by the -a mask command line arg which sets the umask\n (defaults to 0700).\n\nOverview of authentication in IPA\n=================================\n\nThis describes how we currently authenticate and how we plan to\nimprove authentication performance. First some definitions.\n\nThere are 4 major players:\n\n 1. client\n 2. mod_auth_kerb (in Apache process)\n 3. wsgi handler (in IPA wsgi python process)\n 4. ds (directory server)\n\nThere are several resources:\n\n 1. /ipa/ui (unprotected, web UI static resources)\n 2. /ipa/xml (protected, xmlrpc RPC used by command line clients)\n 3. /ipa/json (protected, json RPC used by javascript in web UI)\n 4. ds (protected, wsgi acts as proxy, our LDAP server)\n\nCurrent Model\n-------------\n\nThis describes how things work in our current system for the web UI.\n\n 1. Client requests /ipa/ui, this is unprotected, is static and\n contains no sensitive information. Apache replies with html and\n javascript. The javascript requests /ipa/json.\n\n 2. Client sends post to /ipa/json.\n\n 3. mod_auth_kerb is configured to protect /ipa/json, replies 401\n authenticate negotiate.\n\n 4. Client resends with credentials\n\n 5. mod_auth_kerb validates credentials\n\n a. if invalid replies 403 access denied (stops here)\n\n b. if valid creates temporary ccache, adds KRB5CCNAME to request\n headers\n\n 6. Request passed to wsgi handler\n\n a. validates request, KRB5CCNAME must be present, referrer, etc.\n\n b. ccache saved and used to bind to ds\n\n c. routes to specified RPC handler.\n\n 7. wsgi handler replies to client\n\nProposed new session based optimization\n---------------------------------------\n\nThe round trip negotiate and credential validation in steps 3,4,5 is\nexpensive. This can be avoided if we can cache the client\ncredentials. With client sessions we can store the client credentials\nin the session bound to the client.\n\nA few notes about the session implementation.\n\n * based on session cookies, cookies must be enabled\n\n * session cookie is secure, only passed on secure connections, only\n passed to our URL resource, never visible to client javascript\n etc.\n\n * session cookie has a session id which is used by wsgi handler to\n retrieve client session data from shared multi-process cache.\n\nChanges to Apache's resource protection\n---------------------------------------\n\n * /ipa/json is no longer protected by mod_auth_kerb. This is\n necessary to avoid the negotiate expense in steps 3,4,5\n above. Instead the /ipa/json resource will be protected in our wsgi\n handler via the session cookie.\n\n * A new protected URI is introduced, /ipa/login. This resource\n does no serve any data, it is used exclusively for authentication.\n\nThe new sequence is:\n\n 1. Client requests /ipa/ui, this is unprotected. Apache replies with\n html and javascript. The javascript requests /ipa/json.\n\n 2. Client sends post to /ipa/json, which is unprotected.\n\n 3. wsgi handler obtains session data from session cookie.\n\n a. if ccache is present in session data and is valid\n\n - request is further validated\n\n - ccache is established for bind to ds\n\n - request is routed to RPC handler\n\n - wsgi handler eventually replies to client\n\n b. if ccache is not present or not valid processing continues ...\n\n 4. wsgi handler replies with 401 Unauthorized\n\n 5. client sends request to /ipa/login to obtain session credentials\n\n 6. mod_auth_kerb replies 401 negotiate on /ipa/login\n\n 7. client sends credentials to /ipa/login\n\n 8. mod_auth_kerb validates credentials\n\n a. if valid\n\n - mod_auth_kerb permits access to /ipa/login. wsgi handler is\n invoked and does the following:\n\n * establishes session for client\n\n * retrieves the ccache from KRB5CCNAME and stores it\n\n a. if invalid\n\n - mod_auth_kerb sends 403 access denied (processing stops)\n\n 9. client now posts the same data again to /ipa/json including\n session cookie. Processing repeats starting at step 2 and since\n the session data now contains a valid ccache step 3a executes, a\n successful reply is sent to client.\n\nCommand line client using xmlrpc\n--------------------------------\n\nThe above describes the web UI utilizing the json RPC mechanism. The\nIPA command line tools utilize a xmlrpc RPC mechanism on the same\nHTTP server. Access to the xmlrpc is via the /ipa/xml URI. The json\nand xmlrpc API's are the same, they differ only on how their procedure\ncalls are marshalled and unmarshalled.\n\nUnder the new scheme /ipa/xml will continue to be Kerberos protected\nat all times. Apache's mod_auth_kerb will continue to require the\nclient provides valid Kerberos credentials.\n\nWhen the WSGI handler routes to /ipa/xml the Kerberos credentials will\nbe extracted from the KRB5CCNAME environment variable as provided by\nmod_auth_kerb. Everything else remains the same.\n" ], "previous_source": "", "target": [ "\nПідтримка сеансів у IPA\nJohn Dennis <jdennis@redhat.com>\n\nМета\n=====\n\nЗабезпечити кешування даних сеансів окремих користувачів протягом\nчасу між послідовними запитами. Бажані можливості:\n\n* Безпроблемна інтеграція із мінімальним впливом на наявну інфраструктуру.\n\n* Забезпечення максимального захисту із одночасним збереженням прийнятної\n швидкодії.\n\n* Забезпечення можливості відкликання сеансів (витирання даних).\n\n* Гнучкість і простота у використанні для розробників.\n\n* Максимальне використання наявних технологій і коду для\n запобігання потребі у повторній розробці, зайвій витарні часу та\n для того, щоб скористатися стабільністю випробуваних компонентів,\n які широкого використовуються спільнотою вільного програмного забезпечення.\n\n* Підтримка роботи із декількома незалежними процесами, які спільно\n використовують дані сеансу.\n\n* Система має працювати належним чином як із даними сеансу, так і без них.\n\n* Висока швидкодія системи.\n\n* Не повинно бути прив’язки до певних серверів або програм для перегляду. Має\n бути забезпечено інтеграцію із вибраною нами моделлю WSGI.\n\nПроблеми\n======\n\nКуки\n-------\n\nБільшість реалізацій сеансів засновано на використанні кук. У кук є\nдекілька невиправних недоліків.\n\n* Користувач може вимкнути куки.\n\n* Зберігання кук на боці користувача не є безпечним. Цю проблему може\n бути усунено використанням прапорців, які позначають, що кука\n використовується лише у межах з’єднань HTTP із захистом SSL,\n для певних ресурсів мережі та визначенням того, що строк дії куки\n обмежено строком роботи сеансу. У більшості сучасних програм для\n перегляду інтернету ці правила встановлюються примусово.\n\nДе зберігати дані сеансів?\n----------------------------\n\nДані сеансів можна зберігати або на боці клієнта, або на боці сервера.\nЯкщо зберігати дані сеансів на адресах клієнтів, виникатиме проблема\nіз доступністю даних сеансу, якщо запити обслуговуються незалежними\nсерверами, оскільки дані сеансу передаються разом із запитом. Це\nможе призвести до проблем, пов’язаних із обмеженням на об’єм даних.\nКрім того, зберігання даних на боці клієнта може призвести до\nпроблем із доступом до конфіденційних даних. Втім, ці проблеми можна\nусунути шифруванням даних сеансу так, щоб їх можна було розшифрувати\nлише на сервері.\n\nПоширенішим є підхід, за якого дані сеансу прив’язуються до\nунікальної назви, ідентифікатора сеансу. Цей ідентифікатор сеансу\nпередається на клієнт, а дані сеансу пов’язуються із ідентифікатором\nсеансу на сервері у пов’язаному із ним сховищі даних. Дані сеансу\nотримуються сервером з використанням ідентифікатора сеансу, коли\nотримує запит. Таким чином усуваються розкриття конфіденційних даних\nсеансу на боці клієнта і обмеження на розмір даних. Втім,\nнатомість виникає проблем із доступністю даних сеансу, якщо запити\nобслуговуються декількома процесами на сервері.\n\nДоступність даних сеансу для декількох процесів\n-----------------------------------------------\n\nApache (та інші вебсервери) відгалужують дочірні процеси для паралельної\nобробки. Крім того, вебсервери може бути розгорнуто у фермі, де\nнавантаження від запитів збалансовано у замкнений спосіб шляхом розподілу\nйого між вузлами. У обох випадках дані сеансу не можна зберігати у\nпам’яті процесу, оскільки вона недоступна іншим процесам, — дочірнім\nблизнюкам основного процесу на сервері або процесам сервера на\nпевних вузлах.\n\nТиповим вирішенням цієї проблеми є зберігання даних сеансу у базі\nданих SQL. Коли процес сервера отримує запит, що містить ідентифікатор\nсеансу у своїх даних куки, цей ідентифікатор сеансу використовується\nдля створення запиту до бази даних SQL, а результат запиту долучається\nдо самого запиту під час передавання його ланцюжком обробки запитів.\nЦе, звичайно ж, тягне за собою проблеми із когерентністю даних.\n\nУ IPA впровадження залежності від бази даних SQL є небажаним,\nйого уникнути.\n\nДані сеансу також можна надати у спільне використання незалежних\nпроцесів, якщо зберігати їх у файлах.\n\nАльтернативним вирішенням проблеми, яке набуває значної популярності,\nє використання швидкого сервера кешування у оперативній пам’яті. Дані\nзберігаються у пам’яті одного процесу, щодо них можна надсилати запити,\nїх можна змінювати за допомогою простого протоколу із використанням\nстандартних механізмів роботи із сокетами. Прикладом є memcached.\nТиповим способом використання є оптимізація обробки запитів SQL\nшляхом зберігання результатів запиту SQL у кеші спільного використання\nу оперативній пам’яті, уникаючи витратних дій з базою даних SQL.\nВтім, кеш у пам’яті має значні переваги і у середовищах без SQL.\n\nМожлива реалізація для використання у IPA\n=========================================\n\nСеанси Apache\n---------------\n\nУ Apache 2.3 підтримку сеансів реалізовано за допомогою таких модулів:\n\n mod_session\n Загальна підтримка сеансів на основі кук.\n\n Див. http://httpd.apache.org/docs/2.3/mod/mod_session.html\n\n mod_session_cookie\n Зберігає дані сеансів на боці клієнта.\n\n Див. http://httpd.apache.org/docs/2.3/mod/mod_session_cookie.html\n\n mod_session_crypto\n Шифрує дані сеансів для захисту. Ключ шифрування є спільним\n параметром налаштовування, видимим усім процесам Apache, він\n зберігається у файлі налаштувань.\n\n Див. http://httpd.apache.org/docs/2.3/mod/mod_session_crypto.html\n\n mod_session_dbd\n Зберігає дані сеансу у базі даних SQL, що надає одночасну\n можливість декільком процесам отримувати доступ і спільно\n використовувати дані сеансу.\n\n Див. http://httpd.apache.org/docs/2.3/mod/mod_session_dbd.html\n\nПроблеми, пов’язані із сеансами у Apache\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nХоча у Apache реалізовано загальну підтримку сеансів, а Apache\nє вебсервером, якому ми надаємо перевагу, він створює проблеми\nу роботі з IPA.\n\n * Підтримкою сеансів можна скористатися лише у httpd >= 2.3, версії,\n яка на час написання цього доступна лише у тестовому випуску\n основної гілки розробки. Поточною ж версією у нашому дистрибутиві\n є httpd 2.2. Те саме стосується і інших дистрибутивів.\n\n * Ми могли б створити пакунки і постачати модулі для роботи з сеансами\n як тимчасові пакунки у середовищах з httpd 2.2, але це матиме такі\n наслідки:\n\n - Доведеться виконувати зворотне портування коду. Програмний\n між версіями httpd 2.2 і 2.3 було змінено. Зворотне\n портування не є таким вже складним — технічну його\n демонстрацію вже реалізовано.\n\n - Нам доведеться пакувати і супроводжувати спеціальний\n пакунок Apache. Маємо супроводжувати код і пакувати його\n для дистрибутивів. Варто було б уникнути обох цих дій,\n якщо це можливо.\n\n * Концепція побудови модулів роботи із сеансами у Apache така, що\n керувати цими модулями можна лише з інших модулів Apache.\n Можливості споживачів даних сеансу з керування даними є дуже\n Спрощеними, обмеженими і статичними на час обробки запиту.\n Обробники запитів, які не є рідними модулями Apache (зокрема\n IPA через WSGI), можуть лише вивчати дані сеансу за допомогою\n Заголовків запитів і скидати ці дані у заголовках відповідей.\n\n * Доступ до даних сеансів спільного використання здійснюється\n лише за допомогою SQL.\n\nВтім, використання модулів роботи із сеансами Apache 2.3 надасть\nнам доступ до надійної підтримки сеансів, реалізованої мовою C\nна основі стандартизованих та широковживаних інтерфейсів Apache.\n\nВеббібліотеки Python\n--------------------\n\nМайже в усіх веббібліотеках Python передбачено підтримку сеансів\nна основі кук. Це, зокрема Django, Twisted, Zope, Turbogears.\nНа попередніх етапах розвитку IPA нами було прийнято рішення\nне використовувати ці бібліотеки. Спроби запозичити лише якусь\nчастину цих бібліотек призведуть до проблем із працездатністю,\nоскільки код не працюватиме поза своєю бібліотекою.\n\nСеанси, реалізовані засобами IPA\n--------------------------------\n\nСпочатку нам здавалося, що найпростішим шляхом буде скористатися\nГотовою підтримкою сеансів, найімовірніше тією, яку реалізовано у\nApache. Втім, виявилося, що існує достатньо багато базових модульних\nкомпонентів Python та інших стандартних пакунків, щоб виконати\nозначені вище вимоги із порівняно незначними затратами на реалізацію.\nОскільки ми використовуємо наявні компоненти, складнощі із реалізацією\nмає бути знівельовано використанням компонентів, які вже перевірено\nі у яких є власна підтримка з боку спільноти. Це доволі зважена\nстратегія.\n\nПропоноване рішення\n===================\n\nНаш інтерфейс вебсервера працюватиме за допомогою WSGI, який робитиме\nзворотний виклик для кожного запиту і передаватиме нам контекст\nсередовища для запиту. Надалі ми будемо називати зворотній виклик\nWSGI « application()», правильна назва у межах синтаксису WSGI.\n\nОбробку спільних даних сеансів здійснюватиме memcached. Ми створюватимемо\nодин екземпляр memcached на кожному вузлі сервера, призначений лише для\nIPA. Обмін даними із memcached здійснюватиметься за допомогою сокета UNIX,\nРозташованого у файловій системі за адресою /var/run/ipa_memcached. Сокет\nбуде захищено правами доступу файлової системи і, якщо потрібно, правилом\nSELinux.\n\nУ application() ми вивчаємо куки запиту і, якщо маємо куку сеансу IPA\nіз ідентифікатором сеансу, отримуємо дані сеансу з нашого екземпляра \nmemcached.\n\nДані сеансу будуть словником (dict) Python. Компоненти IPA читатимуть або\nзаписуватимуть свої відомості щодо сеансу шляхом використання попередньо\nузгодженої назви (наприклад ключа) у dict. Це дуже гнучка системи, яка є\nсумісною із тим, як ми передаємо дані у більшості частин IPA.\n\nЯкщо дані сеансу недоступні, буде створено порожній словник даних сеансу.\n\nHow does this session data travel with the request in the IPA\npipeline? In IPA we use the HTTP request/response to implement RPC. In\napplication() we convert the request into a procedure call passing it\narguments derived from the HTTP request. The passed parameters are\nspecific to the RPC method being invoked. The context the RPC call is\nexecuting in is not passed as an RPC parameter.\n\nHow would the contextual information such as session data be bound to\nthe request and hence the RPC call?\n\nIn IPA when a RPC invocation is being prepared from a request we\nrecognize this will only ever be processed serially by one Python\nthread. A thread local dict called \"context\" is allocated for each\nthread. The context dict is cleared in between requests (e.g. RPC method\ninvocations). The per-thread context dict is populated during the\nlifetime of the request and is used as a global data structure unique to\nthe request that various IPA component can read from and write to with\nthe assurance the data is unique to the current request and/or method\ncall.\n\nThe session data dict will be written into the context dict under the\nsession key before the RPC method begins execution. Thus session data\ncan be read and written by any IPA component by accessing\n``context.session``.\n\nWhen the RPC method finishes execution the session data bound to the\nrequest/method is retrieved from the context and written back to the\nmemcached instance. The session ID is set in the response sent back to\nthe client in the ``Set-Cookie`` header along with the flags\ncontrolling it's usage.\n\nПроблеми і подробиці\n--------------------\n\nIPA code cannot depend on session data being present, however it\nshould always update session data with the hope it will be available\nin the future. Session data may not be available because:\n\n * This is the first request from the user and no session data has\n been created yet.\n\n * The user may have cookies disabled.\n\n * The session data may have been flushed. memcached operates with\n a fixed memory allocation and will flush entries on a LRU basis,\n like with any cache there is no guarantee of persistence.\n\n Also we may have have deliberately expired or deleted session\n data, see below.\n\nCookie manipulation is done via the standard Python Cookie module.\n\nSession cookies will be set to only persist as long as the browser has\nthe session open. They will be tagged so the browser only returns\nthe session ID on SSL secured HTTP requests. They will not be visible\nto Javascript in the browser.\n\nSession ID's will be created by using 48 bits of random data and\nconverted to 12 hexadecimal digits. Newly generated session ID's will\nbe checked for prior existence to handle the unlikely case the random\nnumber repeats.\n\nmemcached will have significantly higher performance than a SQL or file\nbased storage solution. Communication is effectively though a pipe\n(UNIX socket) using a very simple protocol and the data is held\nentirely in process memory. memcached also scales easily, it is easy\nto add more memcached processes and distribute the load across them.\nAt this point in time we don't anticipate the need for this.\n\nA very nice feature of the Python memcached module is that when a data\nitem is written to the cache it is done with standard Python pickling\n(pickling is a standard Python mechanism to marshal and unmarshal\nPython objects). We adopt the convention the object written to cache\nwill be a dict to meet our internal data handling conventions. The\npickling code will recursively handle nested objects in the dict. Thus\nwe gain a lot of flexibility using standard Python data structures to\nstore and retrieve our session data without having to author and debug\ncode to marshal and unmarshal the data if some other storage mechanism\nhad been used. This is a significant implementation win. Of course\nsome common sense limitations need to observed when deciding on what\nis written to the session cache keeping in mind the data is shared\nbetween processes and it should not be excessively large (a\nconfigurable option)\n\nWe can set an expiration on memcached entries. We may elect to do that\nto force session data to be refreshed periodically. For example we may\nwish the client to present fresh credentials on a periodic basis even\nif the cached credentials are otherwise within their validity period.\n\nWe can explicitly delete session data if for some reason we believe it\nis stale, invalid or compromised.\n\nmemcached also gives us certain facilities to prevent race conditions\nbetween different processes utilizing the cache. For example you can\ncheck of the entry has been modified since you last read it or use CAS\n(Check And Set) semantics. What has to be protected in terms of cache\ncoherency will likely have to be determined as the session support is\nutilized and different data items are added to the cache. This is very\nmuch data and context specific. Fortunately memcached operations are\natomic.\n\nКонтроль за процесом memcached\n------------------------------\n\nWe need a mechanism to start the memcached process and secure it so\nthat only IPA components can access it.\n\nAlthough memcached ships with both an initscript and systemd unit\nfiles those are for generic instances. We want a memcached instance\ndedicated exclusively to IPA usage. To accomplish this we would install\na systemd unit file or an SysV initscript to control the IPA specific\nmemcached service. ipactl would be extended to know about this\nadditional service. systemd's cgroup facility would give us additional\nmechanisms to integrate the IPA memcached service within a larger IPA\nprocess group.\n\nProtecting the memcached data would be done via file permissions (and\noptionally SELinux policy) on the UNIX domain socket. Although recent\nimplementations of memcached support authentication via SASL this\nintroduces a performance and complexity burden not warranted when\ncached is dedicated to our exclusive use and access controlled by OS\nmechanisms.\n\nConventionally daemons are protected by assigning a system uid and/or\ngid to the daemon. A daemon launched by root will drop it's privileges\nby assuming the effective uid:gid assigned to it. File system access\nis controlled by the OS via the effective identity and SELinux policy\ncan be crafted based on the identity. Thus the memcached UNIX socket\nwould be protected by having it owned by a specific system user and/or\nmembership in a restricted system group (discounting for the moment\nSELinux).\n\nUnfortunately we currently do not have an IPA system uid whose\nidentity our processes operate under nor do we have an IPA system\ngroup. IPA does manage a collection of related processes (daemons) and\nhistorically each has been assigned their own uid. When these\nunrelated processes communicate they mutually authenticate via other\nmechanisms. We do not have much of a history of using shared file\nsystem objects across identities. When file objects are created they\nare typically assigned the identity of daemon needing to access the\nobject and are not accessed by other daemons, or they carry root\nidentity.\n\nWhen our WSGI application runs in Apache it is run as a WSGI\ndaemon. This means when Apache starts up it forks off WSGI processes\nfor us and we are independent of other Apache processes. When WSGI is\nrun in this mode there is the ability to set the uid:gid of the WSGI\nprocess hosting us, however we currently do not take advantage of this\noption. WSGI can be run in other modes as well, only in daemon mode\ncan the uid:gid be independently set from the rest of Apache. All\nprocesses started by Apache can be set to a common uid:gid specified\nin the global Apache configuration, by default it's\napache:apache. Thus when our IPA code executes it is running as\napache:apache.\n\nTo protect our memcached UNIX socket we can do one of two things:\n\n1. Assign it's uid:gid as apache:apache. This would limit access to\n our cache only to processes running under httpd. It's somewhat\n restricted but far from ideal. Any code running in the web server\n could potentially access our cache. It's difficult to control what the\n web server runs and admins may not understand the consequences of\n configuring httpd to serve other things besides IPA.\n\n2. Create an IPA specific uid:gid, for example ipa:ipa. We then configure\n our WSGI application to run as the ipa:ipa user and group. We also\n configure our memcached instance to run as the ipa:ipa user and\n group. In this configuration we are now fully protected, only our WSGI\n code can read & write to our memcached UNIX socket.\n\nHowever there may be unforeseen issues by converting our code to run as\nsomething other than apache:apache. This would require some\ninvestigation and testing.\n\nIPA is dependent on other system daemons, specifically Directory\nServer (ds) and Certificate Server (cs). Currently we configure ds to\nrun under the dirsrv:dirsrv user and group, an identity of our\ncreation. We allow cs to default to it's pkiuser:pkiuser user and\ngroup. Should these other cooperating daemons also run under the\ncommon ipa:ipa user and group identities? At first blush there would\nseem to be an advantage to coalescing all process identities under a\ncommon IPA user and group identity. However these other processes do\nnot depend on user and group permissions when working with external\nagents, processes, etc. Rather they are designed to be stand-alone\nnetwork services which authenticate their clients via other\nmechanisms. They do depend on user and group permission to manage\ntheir own file system objects. If somehow the ipa user and/or group\nwere compromised or malicious code somehow executed under the ipa\nidentity there would be an advantage in having the cooperating\nprocesses cordoned off under their own identities providing one extra\nlayer of protection. (Note, these cooperating daemons may not even be\nco-located on the same node in which case the issue is moot)\n\nThe UNIX socket behavior (ldapi) with Directory Server is as follows:\n\n * Власник сокета: root:root\n\n * Права доступу до сокета: 0666\n\n * When connecting via ldapi you must authenticate as you would\n normally with a TCP socket, except ...\n\n * If autobind is enabled and the uid:gid is available via\n SO_PEERCRED and the uid:gid can be found in the set of users known\n to the Directory Server then that connection will be bound as that\n user.\n\n * Otherwise an anonymous bind will occur.\n\nmemcached UNIX socket behavior is as follows:\n\n * memcached can be invoked with a user argument, no group may be\n specified. The effective uid is the uid of the user argument and\n the effective gid is the primary group of the user, let's call\n this euid:egid\n\n * The socket ownership is: euid:egid\n\n * The socket permissions are 0700 by default, but this can be\n modified by the -a mask command line arg which sets the umask\n (defaults to 0700).\n\nОгляд розпізнавання у IPA\n=========================\n\nThis describes how we currently authenticate and how we plan to\nimprove authentication performance. First some definitions.\n\nІснує 4 основних учасника процесу:\n\n 1. клієнт\n 2. mod_auth_kerb (у процесі Apache)\n 3. wsgi handler (у процесі wsgi pyhon IPA)\n 4. ds (сервер каталогів)\n\nІснує декілька ресурсів:\n\n 1. /ipa/ui (unprotected, web UI static resources)\n 2. /ipa/xml (protected, xmlrpc RPC used by command line clients)\n 3. /ipa/json (protected, json RPC used by javascript in web UI)\n 4. ds (protected, wsgi acts as proxy, our LDAP server)\n\nПоточна модель\n--------------\n\nThis describes how things work in our current system for the web UI.\n\n 1. Client requests /ipa/ui, this is unprotected, is static and\n contains no sensitive information. Apache replies with html and\n javascript. The javascript requests /ipa/json.\n\n 2. Client sends post to /ipa/json.\n\n 3. mod_auth_kerb is configured to protect /ipa/json, replies 401\n authenticate negotiate.\n\n 4. Client resends with credentials\n\n 5. mod_auth_kerb validates credentials\n\n a. if invalid replies 403 access denied (stops here)\n\n b. if valid creates temporary ccache, adds KRB5CCNAME to request\n headers\n\n 6. Request passed to wsgi handler\n\n a. validates request, KRB5CCNAME must be present, referrer, etc.\n\n b. ccache saved and used to bind to ds\n\n c. routes to specified RPC handler.\n\n 7. wsgi handler replies to client\n\nПропонована нова оптимізація на основі сеансів\n----------------------------------------------\n\nThe round trip negotiate and credential validation in steps 3,4,5 is\nexpensive. This can be avoided if we can cache the client\ncredentials. With client sessions we can store the client credentials\nin the session bound to the client.\n\nA few notes about the session implementation.\n\n * based on session cookies, cookies must be enabled\n\n * session cookie is secure, only passed on secure connections, only\n passed to our URL resource, never visible to client javascript\n etc.\n\n * session cookie has a session id which is used by wsgi handler to\n retrieve client session data from shared multi-process cache.\n\nЗміни у захисті ресурсів Apache\n-------------------------------\n\n * /ipa/json is no longer protected by mod_auth_kerb. This is\n necessary to avoid the negotiate expense in steps 3,4,5\n above. Instead the /ipa/json resource will be protected in our wsgi\n handler via the session cookie.\n\n * A new protected URI is introduced, /ipa/login. This resource\n does no serve any data, it is used exclusively for authentication.\n\nНова послідовність дій:\n\n 1. Client requests /ipa/ui, this is unprotected. Apache replies with\n html and javascript. The javascript requests /ipa/json.\n\n 2. Client sends post to /ipa/json, which is unprotected.\n\n 3. wsgi handler obtains session data from session cookie.\n\n a. if ccache is present in session data and is valid\n\n - request is further validated\n\n - ccache is established for bind to ds\n\n - request is routed to RPC handler\n\n - wsgi handler eventually replies to client\n\n b. if ccache is not present or not valid processing continues ...\n\n 4. wsgi handler replies with 401 Unauthorized\n\n 5. client sends request to /ipa/login to obtain session credentials\n\n 6. mod_auth_kerb replies 401 negotiate on /ipa/login\n\n 7. client sends credentials to /ipa/login\n\n 8. mod_auth_kerb validates credentials\n\n a. if valid\n\n - mod_auth_kerb permits access to /ipa/login. wsgi handler is\n invoked and does the following:\n\n * establishes session for client\n\n * retrieves the ccache from KRB5CCNAME and stores it\n\n a. if invalid\n\n - mod_auth_kerb sends 403 access denied (processing stops)\n\n 9. client now posts the same data again to /ipa/json including\n session cookie. Processing repeats starting at step 2 and since\n the session data now contains a valid ccache step 3a executes, a\n successful reply is sent to client.\n\nКлієнт командного рядка з використанням xmlrpc\n----------------------------------------------\n\nВище описано вебінтерфейс користувача із використанням механізму RPC\njson. Інструменти командного рядка IPA використовують механізм RPC\nxmlrpc на тому самому сервері HTTP. Доступ до xmlrpc здійснюється\nчерез адресу /ipa/xml. Програмний інтерфейс json та xmlrpc є\nє однаковим, відмінність полягає лише у побудові і розбиранні їхніх\nвикликів процедур.\n\nУ межах нової схеми /ipa/xml увесь час захищатиметься Kerberos.\nmod_auth_kerb з Apache продовжуватиме вимагати від клієнта\nнадання чинних реєстраційних даних Kerberos.\n\nКоли обробник WSGI пере спрямовуватиметься до /ipa/xml, реєстраційні\nдані Kerberos видобуватимуться зі змінної середовища KRB5CCNAME,\nза вміст якої відповідає mod_auth_kerb. Усе інше залишається тим самим.\n" ], "id_hash": 5266842103080256542, "content_hash": 5266842103080256542, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1284, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 3811, "source_unit": "https://translate.fedoraproject.org/api/units/2727951/?format=api", "priority": 100, "id": 2734095, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=c91794fce22b841e", "url": "https://translate.fedoraproject.org/api/units/2734095/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:27.049201Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nSet a user's password\n\nIf someone other than a user changes that user's password (e.g., Helpdesk\nresets it) then the password will need to be changed the first time it\nis used. This is so the end-user is the only one who knows the password.\n\nThe IPA password policy controls how often a password may be changed,\nwhat strength requirements exist, and the length of the password history.\n\nEXAMPLES:\n\n To reset your own password:\n ipa passwd\n\n To change another user's password:\n ipa passwd tuser1\n" ], "previous_source": "", "target": [ "\nВстановлення пароля користувача\n\nЯкщо якась стороння особа змінює пароль користувача (наприклад його\nвідновлює допоміжний персонал), новий пароль має бути змінено під\nчас його першого використання. Метою такого способу дій є забезпечення\nситуації, коли пароль буде відомий лише тому, хто ним користується.\n\nПравила щодо паролів IPA керують частотою зміни пароля, вимогами щодо\nскладності пароля та об’ємом журналу зміни паролів.\n\nПРИКЛАДИ:\n\n Щоб скинути ваш власний пароль, виконайте команду:\n ipa passwd\n\n Щоб змінити пароль іншого користувача, виконайте команду:\n ipa passwd tuser1\n" ], "id_hash": 8000548797412698125, "content_hash": 8000548797412698125, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1089, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 84, "source_unit": "https://translate.fedoraproject.org/api/units/2717834/?format=api", "priority": 100, "id": 2734096, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=ef07a8be15f6680d", "url": "https://translate.fedoraproject.org/api/units/2734096/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:27.097037Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nSimulate use of Host-based access controls\n\nHBAC rules control who can access what services on what hosts and from where.\nYou can use HBAC to control which users or groups can access a service,\nor group of services, on a target host.\n\nSince applying HBAC rules implies use of a production environment,\nthis plugin aims to provide simulation of HBAC rules evaluation without\nhaving access to the production environment.\n\n Test user coming to a service on a named host against\n existing enabled rules.\n\n ipa hbactest --user= --host= --service=\n [--rules=rules-list] [--nodetail] [--enabled] [--disabled]\n [--srchost= ] [--sizelimit= ]\n\n --user, --host, and --service are mandatory, others are optional.\n\n If --rules is specified simulate enabling of the specified rules and test\n the login of the user using only these rules.\n\n If --enabled is specified, all enabled HBAC rules will be added to simulation\n\n If --disabled is specified, all disabled HBAC rules will be added to simulation\n\n If --nodetail is specified, do not return information about rules matched/not matched.\n\n If both --rules and --enabled are specified, apply simulation to --rules _and_\n all IPA enabled rules.\n\n If no --rules specified, simulation is run against all IPA enabled rules.\n By default there is a IPA-wide limit to number of entries fetched, you can change it\n with --sizelimit option.\n\n If --srchost is specified, it will be ignored. It is left because of compatibility reasons only.\n\nEXAMPLES:\n\n 1. Use all enabled HBAC rules in IPA database to simulate:\n $ ipa hbactest --user=a1a --host=bar --service=sshd\n --------------------\n Access granted: True\n --------------------\n notmatched: my-second-rule\n notmatched: my-third-rule\n notmatched: myrule\n matched: allow_all\n\n 2. Disable detailed summary of how rules were applied:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --nodetail\n --------------------\n Access granted: True\n --------------------\n\n 3. Test explicitly specified HBAC rules:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --rules=my-second-rule,myrule\n ---------------------\n Access granted: False\n ---------------------\n notmatched: my-second-rule\n notmatched: myrule\n\n 4. Use all enabled HBAC rules in IPA database + explicitly specified rules:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --rules=my-second-rule,myrule --enabled\n --------------------\n Access granted: True\n --------------------\n notmatched: my-second-rule\n notmatched: my-third-rule\n notmatched: myrule\n matched: allow_all\n\n 5. Test all disabled HBAC rules in IPA database:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --disabled\n ---------------------\n Access granted: False\n ---------------------\n notmatched: new-rule\n\n 6. Test all disabled HBAC rules in IPA database + explicitly specified rules:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --rules=my-second-rule,myrule --disabled\n ---------------------\n Access granted: False\n ---------------------\n notmatched: my-second-rule\n notmatched: my-third-rule\n notmatched: myrule\n\n 7. Test all (enabled and disabled) HBAC rules in IPA database:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --enabled --disabled\n --------------------\n Access granted: True\n --------------------\n notmatched: my-second-rule\n notmatched: my-third-rule\n notmatched: myrule\n notmatched: new-rule\n matched: allow_all\n" ], "previous_source": "", "target": [ "\nІмітація використання керування доступом на основі вузлів (HBAC)\n\nПравила HBAC керують тим, хто може отримувати доступ до певних служб.\nВи можете скористатися HBAC для керування тим, які користувачі або групи\nна початковому вузлі можуть отримувати доступ до служби або групи служб\nна вузлі призначення\n\nОскільки застосування правил HBAC передбачає використання робочого\nсередовища, це додаток призначено для імітації обробки правил HBAC без\nдоступу до реального середовища\n\n Перевірити відповідність користувача з початкового вузла до служби на іменованому\n вузлі правилам уможливлення доступу.\n\n ipa hbactest --user= --host= --service=\n [--rules=rules-list] [--nodetail] [--enabled] [--disabled]\n [--srchost= ] [--sizelimit= ]\n\n --user, --host і --service є обов’язковими, інші можна не вказувати.\n\n Якщо вказано --rules, імітувати вмикання вказаних правил і перевірити\n можливість входу користувача у разі використання лише цих правил.\n\n Якщо вказано --enabled, додати всі увімкнені правила HBAC до імітації\n\n Якщо вказано --disabled, додати всі вимкнені правила HBAC до імітації\n\n Якщо вказано --nodetail, не повертати даних щодо відповідних і невідповідних\n правил.\n\n Якщо вказано одночасно --rules і --enabled, виконати імітацію --rules _і_\n всіх увімкнених правил IPA.\n\n Якщо не вказано --rules, буде виконано імітацію всіх увімкнених правил IPA.\n\n Якщо вказано --srchost, його буде проігноровано. Цей параметр збережено лише з міркувань сумісності.\n\nПРИКЛАДИ:\n\n 1. Використання всіх увімкнених правил HBAC у базі даних IPA:\n $ ipa hbactest --user=a1a --srchost=foo --host=bar --service=sshd\n --------------------\n Надано доступ: Так\n --------------------\n невідповідне: my-second-rule\n невідповідне: my-third-rule\n невідповідне: myrule\n відповідне: allow_all\n\n 2. Вимикання докладного резюме застосування правил:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --nodetail\n --------------------\n Надано доступ: Так\n --------------------\n\n 3. Перевірити явно вказані правила HBAC:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --rules=my-second-rule,myrule\n ---------------------\n Надано доступ: Ні\n ---------------------\n невідповідне: my-second-rule\n невідповідне: myrule\n\n 4. Використання всіх увімкнених правил HBAC у базі даних IPA + явно вказаних правил:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --rules=my-second-rule,myrule --enabled\n --------------------\n Доступ надано: Так\n --------------------\n невідповідне: my-second-rule\n невідповідне: my-third-rule\n невідповідне: myrule\n відповідне: allow_all\n\n 5. Перевірка всіх вимкнених правил HBAC у базі даних IPA:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --disabled\n ---------------------\n Надано доступ: Ні\n ---------------------\n невідповідне: new-rule\n\n 6. Перевірка всіх вимкнених правил HBAC у базі даних IPA + явно вказані правила:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --rules=my-second-rule,myrule --disabled\n ---------------------\n Надано доступ: Ні\n ---------------------\n невідповідне: my-second-rule\n невідповідне: my-third-rule\n невідповідне: myrule\n\n 7. Перевірка всіх (увімкнених і вимкнених) правил HBAC у базі даних IPA:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --enabled --disabled\n --------------------\n Надано доступ: Так\n --------------------\n невідповідне: my-second-rule\n невідповідне: my-third-rule\n невідповідне: myrule\n невідповідне: new-rule\n відповідне: allow_all\n" ], "id_hash": 7008914484134093664, "content_hash": 7008914484134093664, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1944, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 424, "source_unit": "https://translate.fedoraproject.org/api/units/2727954/?format=api", "priority": 100, "id": 2734097, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=e144aa96a7e72360", "url": "https://translate.fedoraproject.org/api/units/2734097/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:27.115954Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nSimulate use of Host-based access controls\n\nHBAC rules control who can access what services on what hosts.\nYou can use HBAC to control which users or groups can access a service,\nor group of services, on a target host.\n\nSince applying HBAC rules implies use of a production environment,\nthis plugin aims to provide simulation of HBAC rules evaluation without\nhaving access to the production environment.\n\n Test user coming to a service on a named host against\n existing enabled rules.\n\n ipa hbactest --user= --host= --service=\n [--rules=rules-list] [--nodetail] [--enabled] [--disabled]\n [--sizelimit= ]\n\n --user, --host, and --service are mandatory, others are optional.\n\n If --rules is specified simulate enabling of the specified rules and test\n the login of the user using only these rules.\n\n If --enabled is specified, all enabled HBAC rules will be added to simulation\n\n If --disabled is specified, all disabled HBAC rules will be added to simulation\n\n If --nodetail is specified, do not return information about rules matched/not matched.\n\n If both --rules and --enabled are specified, apply simulation to --rules _and_\n all IPA enabled rules.\n\n If no --rules specified, simulation is run against all IPA enabled rules.\n By default there is a IPA-wide limit to number of entries fetched, you can change it\n with --sizelimit option.\n\nEXAMPLES:\n\n 1. Use all enabled HBAC rules in IPA database to simulate:\n $ ipa hbactest --user=a1a --host=bar --service=sshd\n --------------------\n Access granted: True\n --------------------\n Not matched rules: my-second-rule\n Not matched rules: my-third-rule\n Not matched rules: myrule\n Matched rules: allow_all\n\n 2. Disable detailed summary of how rules were applied:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --nodetail\n --------------------\n Access granted: True\n --------------------\n\n 3. Test explicitly specified HBAC rules:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --rules=myrule --rules=my-second-rule\n ---------------------\n Access granted: False\n ---------------------\n Not matched rules: my-second-rule\n Not matched rules: myrule\n\n 4. Use all enabled HBAC rules in IPA database + explicitly specified rules:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --rules=myrule --rules=my-second-rule --enabled\n --------------------\n Access granted: True\n --------------------\n Not matched rules: my-second-rule\n Not matched rules: my-third-rule\n Not matched rules: myrule\n Matched rules: allow_all\n\n 5. Test all disabled HBAC rules in IPA database:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --disabled\n ---------------------\n Access granted: False\n ---------------------\n Not matched rules: new-rule\n\n 6. Test all disabled HBAC rules in IPA database + explicitly specified rules:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --rules=myrule --rules=my-second-rule --disabled\n ---------------------\n Access granted: False\n ---------------------\n Not matched rules: my-second-rule\n Not matched rules: my-third-rule\n Not matched rules: myrule\n\n 7. Test all (enabled and disabled) HBAC rules in IPA database:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --enabled --disabled\n --------------------\n Access granted: True\n --------------------\n Not matched rules: my-second-rule\n Not matched rules: my-third-rule\n Not matched rules: myrule\n Not matched rules: new-rule\n Matched rules: allow_all\n\n\nHBACTEST AND TRUSTED DOMAINS\n\nWhen an external trusted domain is configured in IPA, HBAC rules are also applied\non users accessing IPA resources from the trusted domain. Trusted domain users and\ngroups (and their SIDs) can be then assigned to external groups which can be\nmembers of POSIX groups in IPA which can be used in HBAC rules and thus allowing\naccess to resources protected by the HBAC system.\n\nhbactest plugin is capable of testing access for both local IPA users and users\nfrom the trusted domains, either by a fully qualified user name or by user SID.\nSuch user names need to have a trusted domain specified as a short name\n(DOMAIN\\Administrator) or with a user principal name (UPN), Administrator@ad.test.\n\nPlease note that hbactest executed with a trusted domain user as --user parameter\ncan be only run by members of \"trust admins\" group.\n\nEXAMPLES:\n\n 1. Test if a user from a trusted domain specified by its shortname matches any\n rule:\n\n $ ipa hbactest --user 'DOMAIN\\Administrator' --host `hostname` --service sshd\n --------------------\n Access granted: True\n --------------------\n Matched rules: allow_all\n Matched rules: can_login\n\n 2. Test if a user from a trusted domain specified by its domain name matches\n any rule:\n\n $ ipa hbactest --user 'Administrator@domain.com' --host `hostname` --service sshd\n --------------------\n Access granted: True\n --------------------\n Matched rules: allow_all\n Matched rules: can_login\n\n 3. Test if a user from a trusted domain specified by its SID matches any rule:\n\n $ ipa hbactest --user S-1-5-21-3035198329-144811719-1378114514-500 --host `hostname` --service sshd\n --------------------\n Access granted: True\n --------------------\n Matched rules: allow_all\n Matched rules: can_login\n\n 4. Test if other user from a trusted domain specified by its SID matches any rule:\n\n $ ipa hbactest --user S-1-5-21-3035198329-144811719-1378114514-1203 --host `hostname` --service sshd\n --------------------\n Access granted: True\n --------------------\n Matched rules: allow_all\n Not matched rules: can_login\n\n 5. Test if other user from a trusted domain specified by its shortname matches\n any rule:\n\n $ ipa hbactest --user 'DOMAIN\\Otheruser' --host `hostname` --service sshd\n --------------------\n Access granted: True\n --------------------\n Matched rules: allow_all\n Not matched rules: can_login\n" ], "previous_source": "", "target": [ "\nІмітація використання керування доступом на основі вузлів (HBAC)\n\nПравила HBAC керують тим, хто може отримувати доступ до певних служб на\nпевних вузлах.\nВи можете скористатися HBAC для керування тим, які користувачі або групи\nна початковому вузлі можуть отримувати доступ до служби або групи служб\nна вузлі призначення\n\nОскільки застосування правил HBAC передбачає використання робочого\nсередовища, це додаток призначено для імітації обробки правил HBAC без\nдоступу до реального середовища\n\n Перевірити відповідність користувача з початкового вузла до служби на іменованому\n вузлі правилам уможливлення доступу.\n\n ipa hbactest --user= --host= --service=\n [--rules=rules-list] [--nodetail] [--enabled] [--disabled]\n [--sizelimit= ]\n\n --user, --host і --service є обов’язковими, інші можна не вказувати.\n\n Якщо вказано --rules, імітувати вмикання вказаних правил і перевірити\n можливість входу користувача у разі використання лише цих правил.\n\n Якщо вказано --enabled, додати всі увімкнені правила HBAC до імітації\n\n Якщо вказано --disabled, додати всі вимкнені правила HBAC до імітації\n\n Якщо вказано --nodetail, не повертати даних щодо відповідних і невідповідних\n правил.\n\n Якщо вказано одночасно --rules і --enabled, виконати імітацію --rules _і_\n всіх увімкнених правил IPA.\n\n Якщо не вказано --rules, буде виконано імітацію всіх увімкнених правил IPA.\n\nПРИКЛАДИ:\n\n 1. Використання всіх увімкнених правил HBAC у базі даних IPA:\n $ ipa hbactest --user=a1a --srchost=foo --host=bar --service=sshd\n --------------------\n Надано доступ: Так\n --------------------\n невідповідне: my-second-rule\n невідповідне: my-third-rule\n невідповідне: myrule\n відповідне: allow_all\n\n 2. Вимикання докладного резюме застосування правил:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --nodetail\n --------------------\n Надано доступ: Так\n --------------------\n\n 3. Перевірити явно вказані правила HBAC:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --rules=myrule --rules=my-second-rule\n ---------------------\n Надано доступ: Ні\n ---------------------\n невідповідне: my-second-rule\n невідповідне: myrule\n\n 4. Використання всіх увімкнених правил HBAC у базі даних IPA + явно вказаних правил:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --rules=myrule --rules=my-second-rule\n --enabled\n --------------------\n Доступ надано: Так\n --------------------\n невідповідне: my-second-rule\n невідповідне: my-third-rule\n невідповідне: myrule\n відповідне: allow_all\n\n 5. Перевірка всіх вимкнених правил HBAC у базі даних IPA:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --disabled\n ---------------------\n Надано доступ: Ні\n ---------------------\n невідповідне: new-rule\n\n 6. Перевірка всіх вимкнених правил HBAC у базі даних IPA + явно вказані правила:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --rules=myrule --rules=my-second-rule --disabled\n ---------------------\n Надано доступ: Ні\n ---------------------\n невідповідне: my-second-rule\n невідповідне: my-third-rule\n невідповідне: myrule\n\n 7. Перевірка всіх (увімкнених і вимкнених) правил HBAC у базі даних IPA:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --enabled --disabled\n --------------------\n Надано доступ: Так\n --------------------\n невідповідне: my-second-rule\n невідповідне: my-third-rule\n невідповідне: myrule\n невідповідне: new-rule\n відповідне: allow_all\n\n\nHBACTEST І ДОВІРЕНІ ДОМЕНИ\n\nЯкщо у IPA налаштовано зовнішній довірений домен, правила HBAC також\nзастосовуються до користувачів, що отримують доступ до ресурсів IPA з\nз довіреного домену. Після цього користувачі і групи довіреного домену\n(на їхні SID) може бути прив’язано до зовнішніх груп, які можуть бути\nучасниками груп POSIX у IPA. Такі прив’язки може бути використано у\nправилах HBAC, отже уможливлення доступу до ресурсів, захищених системою\nHBAC.\n\nДодаток hbactest здатен тестувати доступ як для локальних користувачів\nIPA, так і користувачів з довірених доменів, як за повним іменем\nкористувача, так і за SID користувачів. У таких іменах користувачів\nмає бути вказано скорочено довірений домен (ДОМЕН\\Administrator) або\nназву реєстраційного запису користувача (UPN), Administrator@ad.test.\n\nБудь ласка, зауважте, що виконувати hbactest з аргументом користувача\nдовіреного домену у параметрі --user можуть виконувати лише учасники\nгрупи «trust admins».\n\nПРИКЛАД:\n\n 1. Перевірити, чи відповідає користувач з довіреного домену,\n вказаний за коротким іменем, якомусь правилу:\n\n $ ipa hbactest --user 'DOMAIN\\Administrator' --host `hostname` --service sshd\n --------------------\n Надано доступ: Так\n --------------------\n Відповідні правила: allow_all\n Відповідні правила: can_login\n\n 2. Перевірити, чи відповідає користувач з довіреного домену,\n вказаний за назвою його домену, якомусь правилу:\n\n $ ipa hbactest --user 'Administrator@domain.com' --host `hostname` --service sshd\n --------------------\n Надано доступ: Так\n --------------------\n Відповідні правила: allow_all\n Невідповідні правила: can_login\n\n 3. Перевірити, чи відповідає користувач з довіреного домену\n вказаний за SID, якомусь правилу:\n\n $ ipa hbactest --user S-1-5-21-3035198329-144811719-1378114514-500 \\\n --host `hostname` --service sshd\n --------------------\n Надано доступ: Так\n --------------------\n Відповідні правила: allow_all\n Відповідні правила: can_login\n\n 4. Перевірити, чи відповідає інший користувач з довіреного домену,\n вказаний за SID, якомусь правилу:\n\n $ ipa hbactest --user S-1-5-21-3035198329-144811719-1378114514-500 \\\n --host `hostname` --service sshd\n --------------------\n Надано доступ: Так\n --------------------\n Відповідні правила: allow_all\n Відповідні правила: can_login\n\n 5. Перевірити, чи відповідає інший користувач з довіреного домену,\n вказаний за коротким ім’ям, якомусь правилу:\n\n $ ipa hbactest --user 'DOMAIN\\Otheruser' --host `hostname` --service sshd\n --------------------\n Надано доступ: Так\n --------------------\n Відповідні правила: allow_all\n Невідповідні правила: can_login\n" ], "id_hash": 4990478087492997847, "content_hash": 4990478087492997847, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1807, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 769, "source_unit": "https://translate.fedoraproject.org/api/units/2727956/?format=api", "priority": 100, "id": 2734098, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=c541bd61406412d7", "url": "https://translate.fedoraproject.org/api/units/2734098/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:27.135290Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nSimulate use of Host-based access controls\n\nHBAC rules control who can access what services on what hosts.\nYou can use HBAC to control which users or groups can access a service,\nor group of services, on a target host.\n\nSince applying HBAC rules implies use of a production environment,\nthis plugin aims to provide simulation of HBAC rules evaluation without\nhaving access to the production environment.\n\n Test user coming to a service on a named host against\n existing enabled rules.\n\n ipa hbactest --user= --host= --service=\n [--rules=rules-list] [--nodetail] [--enabled] [--disabled]\n [--sizelimit= ]\n\n --user, --host, and --service are mandatory, others are optional.\n\n If --rules is specified simulate enabling of the specified rules and test\n the login of the user using only these rules.\n\n If --enabled is specified, all enabled HBAC rules will be added to simulation\n\n If --disabled is specified, all disabled HBAC rules will be added to simulation\n\n If --nodetail is specified, do not return information about rules matched/not matched.\n\n If both --rules and --enabled are specified, apply simulation to --rules _and_\n all IPA enabled rules.\n\n If no --rules specified, simulation is run against all IPA enabled rules.\n By default there is a IPA-wide limit to number of entries fetched, you can change it\n with --sizelimit option.\n\nEXAMPLES:\n\n 1. Use all enabled HBAC rules in IPA database to simulate:\n $ ipa hbactest --user=a1a --host=bar --service=sshd\n --------------------\n Access granted: True\n --------------------\n Not matched rules: my-second-rule\n Not matched rules: my-third-rule\n Not matched rules: myrule\n Matched rules: allow_all\n\n 2. Disable detailed summary of how rules were applied:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --nodetail\n --------------------\n Access granted: True\n --------------------\n\n 3. Test explicitly specified HBAC rules:\n $ ipa hbactest --user=a1a --host=bar --service=sshd \\\n --rules=myrule --rules=my-second-rule\n ---------------------\n Access granted: False\n ---------------------\n Not matched rules: my-second-rule\n Not matched rules: myrule\n\n 4. Use all enabled HBAC rules in IPA database + explicitly specified rules:\n $ ipa hbactest --user=a1a --host=bar --service=sshd \\\n --rules=myrule --rules=my-second-rule --enabled\n --------------------\n Access granted: True\n --------------------\n Not matched rules: my-second-rule\n Not matched rules: my-third-rule\n Not matched rules: myrule\n Matched rules: allow_all\n\n 5. Test all disabled HBAC rules in IPA database:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --disabled\n ---------------------\n Access granted: False\n ---------------------\n Not matched rules: new-rule\n\n 6. Test all disabled HBAC rules in IPA database + explicitly specified rules:\n $ ipa hbactest --user=a1a --host=bar --service=sshd \\\n --rules=myrule --rules=my-second-rule --disabled\n ---------------------\n Access granted: False\n ---------------------\n Not matched rules: my-second-rule\n Not matched rules: my-third-rule\n Not matched rules: myrule\n\n 7. Test all (enabled and disabled) HBAC rules in IPA database:\n $ ipa hbactest --user=a1a --host=bar --service=sshd \\\n --enabled --disabled\n --------------------\n Access granted: True\n --------------------\n Not matched rules: my-second-rule\n Not matched rules: my-third-rule\n Not matched rules: myrule\n Not matched rules: new-rule\n Matched rules: allow_all\n\n\nHBACTEST AND TRUSTED DOMAINS\n\nWhen an external trusted domain is configured in IPA, HBAC rules are also applied\non users accessing IPA resources from the trusted domain. Trusted domain users and\ngroups (and their SIDs) can be then assigned to external groups which can be\nmembers of POSIX groups in IPA which can be used in HBAC rules and thus allowing\naccess to resources protected by the HBAC system.\n\nhbactest plugin is capable of testing access for both local IPA users and users\nfrom the trusted domains, either by a fully qualified user name or by user SID.\nSuch user names need to have a trusted domain specified as a short name\n(DOMAIN\\Administrator) or with a user principal name (UPN), Administrator@ad.test.\n\nPlease note that hbactest executed with a trusted domain user as --user parameter\ncan be only run by members of \"trust admins\" group.\n\nEXAMPLES:\n\n 1. Test if a user from a trusted domain specified by its shortname matches any\n rule:\n\n $ ipa hbactest --user 'DOMAIN\\Administrator' --host `hostname` --service sshd\n --------------------\n Access granted: True\n --------------------\n Matched rules: allow_all\n Matched rules: can_login\n\n 2. Test if a user from a trusted domain specified by its domain name matches\n any rule:\n\n $ ipa hbactest --user 'Administrator@domain.com' --host `hostname` --service sshd\n --------------------\n Access granted: True\n --------------------\n Matched rules: allow_all\n Matched rules: can_login\n\n 3. Test if a user from a trusted domain specified by its SID matches any rule:\n\n $ ipa hbactest --user S-1-5-21-3035198329-144811719-1378114514-500 \\\n --host `hostname` --service sshd\n --------------------\n Access granted: True\n --------------------\n Matched rules: allow_all\n Matched rules: can_login\n\n 4. Test if other user from a trusted domain specified by its SID matches any rule:\n\n $ ipa hbactest --user S-1-5-21-3035198329-144811719-1378114514-1203 \\\n --host `hostname` --service sshd\n --------------------\n Access granted: True\n --------------------\n Matched rules: allow_all\n Not matched rules: can_login\n\n 5. Test if other user from a trusted domain specified by its shortname matches\n any rule:\n\n $ ipa hbactest --user 'DOMAIN\\Otheruser' --host `hostname` --service sshd\n --------------------\n Access granted: True\n --------------------\n Matched rules: allow_all\n Not matched rules: can_login\n" ], "previous_source": "", "target": [ "\nІмітація використання керування доступом на основі вузлів (HBAC)\n\nПравила HBAC керують тим, хто може отримувати доступ до певних служб на\nпевних вузлах.\nВи можете скористатися HBAC для керування тим, які користувачі або групи\nна початковому вузлі можуть отримувати доступ до служби або групи служб\nна вузлі призначення\n\nОскільки застосування правил HBAC передбачає використання робочого\nсередовища, це додаток призначено для імітації обробки правил HBAC без\nдоступу до реального середовища\n\n Перевірити відповідність користувача з початкового вузла до служби на іменованому\n вузлі правилам уможливлення доступу.\n\n ipa hbactest --user= --host= --service=\n [--rules=rules-list] [--nodetail] [--enabled] [--disabled]\n [--sizelimit= ]\n\n --user, --host і --service є обов’язковими, інші можна не вказувати.\n\n Якщо вказано --rules, імітувати вмикання вказаних правил і перевірити\n можливість входу користувача у разі використання лише цих правил.\n\n Якщо вказано --enabled, додати всі увімкнені правила HBAC до імітації\n\n Якщо вказано --disabled, додати всі вимкнені правила HBAC до імітації\n\n Якщо вказано --nodetail, не повертати даних щодо відповідних і невідповідних\n правил.\n\n Якщо вказано одночасно --rules і --enabled, виконати імітацію --rules _і_\n всіх увімкнених правил IPA.\n\n Якщо не вказано --rules, буде виконано імітацію всіх увімкнених правил IPA.\n\nПРИКЛАДИ:\n\n 1. Використання всіх увімкнених правил HBAC у базі даних IPA:\n $ ipa hbactest --user=a1a --srchost=foo --host=bar --service=sshd\n --------------------\n Надано доступ: Так\n --------------------\n невідповідне: my-second-rule\n невідповідне: my-third-rule\n невідповідне: myrule\n відповідне: allow_all\n\n 2. Вимикання докладного резюме застосування правил:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --nodetail\n --------------------\n Надано доступ: Так\n --------------------\n\n 3. Перевірити явно вказані правила HBAC:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --rules=my-second-rule,myrule\n ---------------------\n Надано доступ: Ні\n ---------------------\n невідповідне: my-second-rule\n невідповідне: myrule\n\n 4. Використання всіх увімкнених правил HBAC у базі даних IPA + явно вказаних правил:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --rules=my-second-rule,myrule --enabled\n --------------------\n Доступ надано: Так\n --------------------\n невідповідне: my-second-rule\n невідповідне: my-third-rule\n невідповідне: myrule\n відповідне: allow_all\n\n 5. Перевірка всіх вимкнених правил HBAC у базі даних IPA:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --disabled\n ---------------------\n Надано доступ: Ні\n ---------------------\n невідповідне: new-rule\n\n 6. Перевірка всіх вимкнених правил HBAC у базі даних IPA + явно вказані правила:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --rules=my-second-rule,myrule --disabled\n ---------------------\n Надано доступ: Ні\n ---------------------\n невідповідне: my-second-rule\n невідповідне: my-third-rule\n невідповідне: myrule\n\n 7. Перевірка всіх (увімкнених і вимкнених) правил HBAC у базі даних IPA:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --enabled --disabled\n --------------------\n Надано доступ: Так\n --------------------\n невідповідне: my-second-rule\n невідповідне: my-third-rule\n невідповідне: myrule\n невідповідне: new-rule\n відповідне: allow_all\n\n\nHBACTEST І ДОВІРЕНІ ДОМЕНИ\n\nЯкщо у IPA налаштовано зовнішній довірений домен, правила HBAC також\nзастосовуються до користувачів, що отримують доступ до ресурсів IPA з\nз довіреного домену. Після цього користувачі і групи довіреного домену\n(на їхні SID) може бути прив’язано до зовнішніх груп, які можуть бути\nучасниками груп POSIX у IPA. Такі прив’язки може бути використано у\nправилах HBAC, отже уможливлення доступу до ресурсів, захищених системою\nHBAC.\n\nДодаток hbactest здатен тестувати доступ як для локальних користувачів\nIPA, так і користувачів з довірених доменів, як за повним іменем\nкористувача, так і за SID користувачів. У таких іменах користувачів\nмає бути вказано скорочено довірений домен (ДОМЕН\\Administrator) або\nназву реєстраційного запису користувача (UPN), Administrator@ad.test.\n\nБудь ласка, зауважте, що виконувати hbactest з аргументом користувача\nдовіреного домену у параметрі --user можуть виконувати лише учасники\nгрупи «trust admins».\n\nПРИКЛАД:\n\n 1. Перевірити, чи відповідає користувач з довіреного домену,\n вказаний за коротким іменем, якомусь правилу:\n\n $ ipa hbactest --user 'DOMAIN\\Administrator' --host `hostname` --service sshd\n --------------------\n Надано доступ: Так\n --------------------\n Відповідні правила: allow_all\n Відповідні правила: can_login\n\n 2. Перевірити, чи відповідає користувач з довіреного домену,\n вказаний за назвою його домену, якомусь правилу:\n\n $ ipa hbactest --user 'Administrator@domain.com' --host `hostname` --service sshd\n --------------------\n Надано доступ: Так\n --------------------\n Відповідні правила: allow_all\n Невідповідні правила: can_login\n\n 3. Перевірити, чи відповідає користувач з довіреного домену\n вказаний за SID, якомусь правилу:\n\n $ ipa hbactest --user S-1-5-21-3035198329-144811719-1378114514-500 \\\n --host `hostname` --service sshd\n --------------------\n Надано доступ: Так\n --------------------\n Відповідні правила: allow_all\n Відповідні правила: can_login\n\n 4. Перевірити, чи відповідає інший користувач з довіреного домену,\n вказаний за SID, якомусь правилу:\n\n $ ipa hbactest --user S-1-5-21-3035198329-144811719-1378114514-500 \\\n --host `hostname` --service sshd\n --------------------\n Надано доступ: Так\n --------------------\n Відповідні правила: allow_all\n Відповідні правила: can_login\n\n 5. Перевірити, чи відповідає інший користувач з довіреного домену,\n вказаний за коротким ім’ям, якомусь правилу:\n\n $ ipa hbactest --user 'DOMAIN\\Otheruser' --host `hostname` --service sshd\n --------------------\n Надано доступ: Так\n --------------------\n Відповідні правила: allow_all\n Невідповідні правила: can_login\n" ], "id_hash": -3951241149242460815, "content_hash": -3951241149242460815, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1526, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 775, "source_unit": "https://translate.fedoraproject.org/api/units/2722420/?format=api", "priority": 100, "id": 2734099, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=492a5f1bfd7f3571", "url": "https://translate.fedoraproject.org/api/units/2734099/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:27.158990Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nSimulate use of Host-based access controls\n\nHBAC rules control who can access what services on what hosts.\nYou can use HBAC to control which users or groups can access a service,\nor group of services, on a target host.\n\nSince applying HBAC rules implies use of a production environment,\nthis plugin aims to provide simulation of HBAC rules evaluation without\nhaving access to the production environment.\n\n Test user coming to a service on a named host against\n existing enabled rules.\n\n ipa hbactest --user= --host= --service=\n [--rules=rules-list] [--nodetail] [--enabled] [--disabled]\n [--sizelimit= ]\n\n --user, --host, and --service are mandatory, others are optional.\n\n If --rules is specified simulate enabling of the specified rules and test\n the login of the user using only these rules.\n\n If --enabled is specified, all enabled HBAC rules will be added to simulation\n\n If --disabled is specified, all disabled HBAC rules will be added to simulation\n\n If --nodetail is specified, do not return information about rules matched/not matched.\n\n If both --rules and --enabled are specified, apply simulation to --rules _and_\n all IPA enabled rules.\n\n If no --rules specified, simulation is run against all IPA enabled rules.\n By default there is a IPA-wide limit to number of entries fetched, you can change it\n with --sizelimit option.\n\nEXAMPLES:\n\n 1. Use all enabled HBAC rules in IPA database to simulate:\n $ ipa hbactest --user=a1a --host=bar --service=sshd\n --------------------\n Access granted: True\n --------------------\n Not matched rules: my-second-rule\n Not matched rules: my-third-rule\n Not matched rules: myrule\n Matched rules: allow_all\n\n 2. Disable detailed summary of how rules were applied:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --nodetail\n --------------------\n Access granted: True\n --------------------\n\n 3. Test explicitly specified HBAC rules:\n $ ipa hbactest --user=a1a --host=bar --service=sshd \\\\\n --rules=myrule --rules=my-second-rule\n ---------------------\n Access granted: False\n ---------------------\n Not matched rules: my-second-rule\n Not matched rules: myrule\n\n 4. Use all enabled HBAC rules in IPA database + explicitly specified rules:\n $ ipa hbactest --user=a1a --host=bar --service=sshd \\\\\n --rules=myrule --rules=my-second-rule --enabled\n --------------------\n Access granted: True\n --------------------\n Not matched rules: my-second-rule\n Not matched rules: my-third-rule\n Not matched rules: myrule\n Matched rules: allow_all\n\n 5. Test all disabled HBAC rules in IPA database:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --disabled\n ---------------------\n Access granted: False\n ---------------------\n Not matched rules: new-rule\n\n 6. Test all disabled HBAC rules in IPA database + explicitly specified rules:\n $ ipa hbactest --user=a1a --host=bar --service=sshd \\\\\n --rules=myrule --rules=my-second-rule --disabled\n ---------------------\n Access granted: False\n ---------------------\n Not matched rules: my-second-rule\n Not matched rules: my-third-rule\n Not matched rules: myrule\n\n 7. Test all (enabled and disabled) HBAC rules in IPA database:\n $ ipa hbactest --user=a1a --host=bar --service=sshd \\\\\n --enabled --disabled\n --------------------\n Access granted: True\n --------------------\n Not matched rules: my-second-rule\n Not matched rules: my-third-rule\n Not matched rules: myrule\n Not matched rules: new-rule\n Matched rules: allow_all\n\n\nHBACTEST AND TRUSTED DOMAINS\n\nWhen an external trusted domain is configured in IPA, HBAC rules are also applied\non users accessing IPA resources from the trusted domain. Trusted domain users and\ngroups (and their SIDs) can be then assigned to external groups which can be\nmembers of POSIX groups in IPA which can be used in HBAC rules and thus allowing\naccess to resources protected by the HBAC system.\n\nhbactest plugin is capable of testing access for both local IPA users and users\nfrom the trusted domains, either by a fully qualified user name or by user SID.\nSuch user names need to have a trusted domain specified as a short name\n(DOMAIN\\Administrator) or with a user principal name (UPN), Administrator@ad.test.\n\nPlease note that hbactest executed with a trusted domain user as --user parameter\ncan be only run by members of \"trust admins\" group.\n\nEXAMPLES:\n\n 1. Test if a user from a trusted domain specified by its shortname matches any\n rule:\n\n $ ipa hbactest --user 'DOMAIN\\Administrator' --host `hostname` --service sshd\n --------------------\n Access granted: True\n --------------------\n Matched rules: allow_all\n Matched rules: can_login\n\n 2. Test if a user from a trusted domain specified by its domain name matches\n any rule:\n\n $ ipa hbactest --user 'Administrator@domain.com' --host `hostname` --service sshd\n --------------------\n Access granted: True\n --------------------\n Matched rules: allow_all\n Matched rules: can_login\n\n 3. Test if a user from a trusted domain specified by its SID matches any rule:\n\n $ ipa hbactest --user S-1-5-21-3035198329-144811719-1378114514-500 \\\\\n --host `hostname` --service sshd\n --------------------\n Access granted: True\n --------------------\n Matched rules: allow_all\n Matched rules: can_login\n\n 4. Test if other user from a trusted domain specified by its SID matches any rule:\n\n $ ipa hbactest --user S-1-5-21-3035198329-144811719-1378114514-1203 \\\\\n --host `hostname` --service sshd\n --------------------\n Access granted: True\n --------------------\n Matched rules: allow_all\n Not matched rules: can_login\n\n 5. Test if other user from a trusted domain specified by its shortname matches\n any rule:\n\n $ ipa hbactest --user 'DOMAIN\\Otheruser' --host `hostname` --service sshd\n --------------------\n Access granted: True\n --------------------\n Matched rules: allow_all\n Not matched rules: can_login\n" ], "previous_source": "", "target": [ "\nІмітація використання керування доступом на основі вузлів (HBAC)\n\nПравила HBAC керують тим, хто може отримувати доступ до певних служб на\nпевних вузлах.\nВи можете скористатися HBAC для керування тим, які користувачі або групи\nна початковому вузлі можуть отримувати доступ до служби або групи служб\nна вузлі призначення\n\nОскільки застосування правил HBAC передбачає використання робочого\nсередовища, це додаток призначено для імітації обробки правил HBAC без\nдоступу до реального середовища\n\n Перевірити відповідність користувача з початкового вузла до служби на іменованому\n вузлі правилам уможливлення доступу.\n\n ipa hbactest --user= --host= --service=\n [--rules=rules-list] [--nodetail] [--enabled] [--disabled]\n [--sizelimit= ]\n\n --user, --host і --service є обов’язковими, інші можна не вказувати.\n\n Якщо вказано --rules, імітувати вмикання вказаних правил і перевірити\n можливість входу користувача у разі використання лише цих правил.\n\n Якщо вказано --enabled, додати всі увімкнені правила HBAC до імітації\n\n Якщо вказано --disabled, додати всі вимкнені правила HBAC до імітації\n\n Якщо вказано --nodetail, не повертати даних щодо відповідних і невідповідних\n правил.\n\n Якщо вказано одночасно --rules і --enabled, виконати імітацію --rules _і_\n всіх увімкнених правил IPA.\n\n Якщо не вказано --rules, буде виконано імітацію всіх увімкнених правил IPA.\n\nПРИКЛАДИ:\n\n 1. Використання всіх увімкнених правил HBAC у базі даних IPA:\n $ ipa hbactest --user=a1a --srchost=foo --host=bar --service=sshd\n --------------------\n Надано доступ: Так\n --------------------\n невідповідне: my-second-rule\n невідповідне: my-third-rule\n невідповідне: myrule\n відповідне: allow_all\n\n 2. Вимикання докладного резюме застосування правил:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --nodetail\n --------------------\n Надано доступ: Так\n --------------------\n\n 3. Перевірити явно вказані правила HBAC:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --rules=my-second-rule,myrule\n ---------------------\n Надано доступ: Ні\n ---------------------\n невідповідне: my-second-rule\n невідповідне: myrule\n\n 4. Використання всіх увімкнених правил HBAC у базі даних IPA + явно вказаних правил:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --rules=my-second-rule,myrule --enabled\n --------------------\n Доступ надано: Так\n --------------------\n невідповідне: my-second-rule\n невідповідне: my-third-rule\n невідповідне: myrule\n відповідне: allow_all\n\n 5. Перевірка всіх вимкнених правил HBAC у базі даних IPA:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --disabled\n ---------------------\n Надано доступ: Ні\n ---------------------\n невідповідне: new-rule\n\n 6. Перевірка всіх вимкнених правил HBAC у базі даних IPA + явно вказані правила:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --rules=my-second-rule,myrule --disabled\n ---------------------\n Надано доступ: Ні\n ---------------------\n невідповідне: my-second-rule\n невідповідне: my-third-rule\n невідповідне: myrule\n\n 7. Перевірка всіх (увімкнених і вимкнених) правил HBAC у базі даних IPA:\n $ ipa hbactest --user=a1a --host=bar --service=sshd --enabled --disabled\n --------------------\n Надано доступ: Так\n --------------------\n невідповідне: my-second-rule\n невідповідне: my-third-rule\n невідповідне: myrule\n невідповідне: new-rule\n відповідне: allow_all\n\n\nHBACTEST І ДОВІРЕНІ ДОМЕНИ\n\nЯкщо у IPA налаштовано зовнішній довірений домен, правила HBAC також\nзастосовуються до користувачів, що отримують доступ до ресурсів IPA з\nз довіреного домену. Після цього користувачі і групи довіреного домену\n(на їхні SID) може бути прив’язано до зовнішніх груп, які можуть бути\nучасниками груп POSIX у IPA. Такі прив’язки може бути використано у\nправилах HBAC, отже уможливлення доступу до ресурсів, захищених системою\nHBAC.\n\nДодаток hbactest здатен тестувати доступ як для локальних користувачів\nIPA, так і користувачів з довірених доменів, як за повним іменем\nкористувача, так і за SID користувачів. У таких іменах користувачів\nмає бути вказано скорочено довірений домен (ДОМЕН\\Administrator) або\nназву реєстраційного запису користувача (UPN), Administrator@ad.test.\n\nБудь ласка, зауважте, що виконувати hbactest з аргументом користувача\nдовіреного домену у параметрі --user можуть виконувати лише учасники\nгрупи «trust admins».\n\nПРИКЛАД:\n\n 1. Перевірити, чи відповідає користувач з довіреного домену,\n вказаний за коротким іменем, якомусь правилу:\n\n $ ipa hbactest --user 'DOMAIN\\Administrator' --host `hostname` --service sshd\n --------------------\n Надано доступ: Так\n --------------------\n Відповідні правила: allow_all\n Відповідні правила: can_login\n\n 2. Перевірити, чи відповідає користувач з довіреного домену,\n вказаний за назвою його домену, якомусь правилу:\n\n $ ipa hbactest --user 'Administrator@domain.com' --host `hostname` --service sshd\n --------------------\n Надано доступ: Так\n --------------------\n Відповідні правила: allow_all\n Невідповідні правила: can_login\n\n 3. Перевірити, чи відповідає користувач з довіреного домену\n вказаний за SID, якомусь правилу:\n\n $ ipa hbactest --user S-1-5-21-3035198329-144811719-1378114514-500 \\\n --host `hostname` --service sshd\n --------------------\n Надано доступ: Так\n --------------------\n Відповідні правила: allow_all\n Відповідні правила: can_login\n\n 4. Перевірити, чи відповідає інший користувач з довіреного домену,\n вказаний за SID, якомусь правилу:\n\n $ ipa hbactest --user S-1-5-21-3035198329-144811719-1378114514-500 \\\n --host `hostname` --service sshd\n --------------------\n Надано доступ: Так\n --------------------\n Відповідні правила: allow_all\n Відповідні правила: can_login\n\n 5. Перевірити, чи відповідає інший користувач з довіреного домену,\n вказаний за коротким ім’ям, якомусь правилу:\n\n $ ipa hbactest --user 'DOMAIN\\Otheruser' --host `hostname` --service sshd\n --------------------\n Надано доступ: Так\n --------------------\n Відповідні правила: allow_all\n Невідповідні правила: can_login\n" ], "id_hash": 7203526444516297681, "content_hash": 7203526444516297681, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 3865, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 775, "source_unit": "https://translate.fedoraproject.org/api/units/2727959/?format=api", "priority": 100, "id": 2734100, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=e3f81122a786cbd1", "url": "https://translate.fedoraproject.org/api/units/2734100/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:27.184200Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nStageusers\n\nManage stage user entries.\n\nStage user entries are directly under the container: \"cn=stage users,\ncn=accounts, cn=provisioning, SUFFIX\".\nUser can not authenticate with those entries (even if the entries\ncontain credentials) and are candidate to become Active entries.\n\nActive user entries are Posix users directly under the container: \"cn=accounts, SUFFIX\".\nUser can authenticate with Active entries, at the condition they have\ncredentials\n\nDelete user entries are Posix users directly under the container: \"cn=deleted users,\ncn=accounts, cn=provisioning, SUFFIX\".\nUser can not authenticate with those entries (even if the entries contain credentials)\n\nThe stage user container contains entries\n - created by 'stageuser-add' commands that are Posix users\n - created by external provisioning system\n\nA valid stage user entry MUST:\n - entry RDN is 'uid'\n - ipaUniqueID is 'autogenerate'\n\nIPA supports a wide range of username formats, but you need to be aware of any\nrestrictions that may apply to your particular environment. For example,\nusernames that start with a digit or usernames that exceed a certain length\nmay cause problems for some UNIX systems.\nUse 'ipa config-mod' to change the username format allowed by IPA tools.\n\n\nEXAMPLES:\n\n Add a new stageuser:\n ipa stageuser-add --first=Tim --last=User --password tuser1\n\n Add a stageuser from the Delete container\n ipa stageuser-add --first=Tim --last=User --from-delete tuser1\n" ], "previous_source": "", "target": [ "\nКористувачі етапу\n\nКерування записами користувачів етапу.\n\nЗаписи користувачів етапу перебувають безпосередньо у контейнері:\n\"cn=stage users, cn=accounts, cn=provisioning, SUFFIX\".\nКористувач не може пройти розпізнавання за допомогою цих записів\n(навіть якщо записи містять реєстраційні дані) і є кандидатами на\nперетворення на активні записи.\n\nЗаписи активних користувачів є користувачами Posix, що перебувають\nбезпосередньо у контейнері: \"cn=accounts, SUFFIX\".\nКористувач може пройти розпізнавання за допомогою активних записів,\nякщо для них передбачено реєстраційні дані\n\nВилучені записи користувачів є записами користувачів Posix, що\nперебувають безпосередньо у контейнері: \"cn=deleted users,\ncn=accounts, cn=provisioning, SUFFIX\".\nКористувачі не можуть проходити розпізнавання за допомогою цих\nзаписів (навіть якщо записи містять реєстраційні дані)\n\nКонтейнер користувачів етапу містить записи\n - створені командами 'stageuser-add', які є користувачами Posix\n - створені зовнішньою системою забезпечення\n\nКоректний запис користувача етапу МАЄ відповідати таким вимогам:\n - RDN запису має значення 'uid'\n - ipaUniqueID має значення 'autogenerate'\n\nУ IPA передбачено підтримку широкого діапазону форматів імен користувачів,\nале слід зважати на різноманітні обмеження, які можуть стосуватися середовища,\nу якому ви працюєте. Наприклад, імена користувачів, що починаються з цифри,\nабо імена користувачів, довжина яких перевищує певну довжину, що може\nпризвести до проблем у деяких системах UNIX.\nДля зміни формату, який дозволено інструментами IPA, скористайтеся командою\n'ipa config-mod'.\n\n\nПРИКЛАДИ:\n\n Додати нового користувача етапу:\n ipa stageuser-add --first=Tim --last=User --password tuser1\n\n Додати користувача етапу з контейнера Delete\n ipa stageuser-add --first=Tim --last=User --from-delete tuser1\n" ], "id_hash": -6243864614975504312, "content_hash": -6243864614975504312, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1693, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 208, "source_unit": "https://translate.fedoraproject.org/api/units/2727961/?format=api", "priority": 100, "id": 2734101, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=29595636cec10048", "url": "https://translate.fedoraproject.org/api/units/2734101/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:27.205328Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nStageusers\n\nManage stage user entries.\n\nStage user entries are directly under the container: \"cn=stage users,\ncn=accounts, cn=provisioning, SUFFIX\".\nUsers can not authenticate with those entries (even if the entries\ncontain credentials). Those entries are only candidate to become Active entries.\n\nActive user entries are Posix users directly under the container: \"cn=accounts, SUFFIX\".\nUsers can authenticate with Active entries, at the condition they have\ncredentials.\n\nDeleted user entries are Posix users directly under the container: \"cn=deleted users,\ncn=accounts, cn=provisioning, SUFFIX\".\nUsers can not authenticate with those entries, even if the entries contain credentials.\n\nThe stage user container contains entries:\n - created by 'stageuser-add' commands that are Posix users,\n - created by external provisioning system.\n\nA valid stage user entry MUST have:\n - entry RDN is 'uid',\n - ipaUniqueID is 'autogenerate'.\n\nIPA supports a wide range of username formats, but you need to be aware of any\nrestrictions that may apply to your particular environment. For example,\nusernames that start with a digit or usernames that exceed a certain length\nmay cause problems for some UNIX systems.\nUse 'ipa config-mod' to change the username format allowed by IPA tools.\n\n\nEXAMPLES:\n\n Add a new stageuser:\n ipa stageuser-add --first=Tim --last=User --password tuser1\n\n Add a stageuser from the deleted users container:\n ipa stageuser-add --first=Tim --last=User --from-delete tuser1\n\n" ], "previous_source": "", "target": [ "\nКористувачі етапу\n\nКерування записами користувачів етапу.\n\nЗаписи користувачів етапу перебувають безпосередньо у контейнері:\n\"cn=stage users, cn=accounts, cn=provisioning, SUFFIX\".\nКористувач не може пройти розпізнавання за допомогою цих записів\n(навіть якщо записи містять реєстраційні дані) і є кандидатами на\nперетворення на активні записи.\n\nЗаписи активних користувачів є користувачами Posix, що перебувають\nбезпосередньо у контейнері: \"cn=accounts, SUFFIX\".\nКористувач може пройти розпізнавання за допомогою активних записів,\nякщо для них передбачено реєстраційні дані\n\nВилучені записи користувачів є записами користувачів Posix, що\nперебувають безпосередньо у контейнері: \"cn=deleted users,\ncn=accounts, cn=provisioning, SUFFIX\".\nКористувачі не можуть проходити розпізнавання за допомогою цих\nзаписів (навіть якщо записи містять реєстраційні дані)\n\nКонтейнер користувачів етапу містить записи\n - створені командами 'stageuser-add', які є користувачами Posix\n - створені зовнішньою системою забезпечення\n\nКоректний запис користувача етапу МАЄ відповідати таким вимогам:\n - RDN запису має значення 'uid'\n - ipaUniqueID має значення 'autogenerate'\n\nУ IPA передбачено підтримку широкого діапазону форматів імен користувачів,\nале слід зважати на різноманітні обмеження, які можуть стосуватися середовища,\nу якому ви працюєте. Наприклад, імена користувачів, що починаються з цифри,\nабо імена користувачів, довжина яких перевищує певну довжину, можуть\nпризвести до проблем у деяких системах UNIX.\nДля зміни формату, який дозволено інструментами IPA, скористайтеся командою\n'ipa config-mod'.\n\n\nПРИКЛАДИ:\n\n Додати нового користувача етапу:\n ipa stageuser-add --first=Tim --last=User --password tuser1\n\n Додати користувача етапу з контейнера вилучених користувачів\n ipa stageuser-add --first=Tim --last=User --from-delete tuser1\n\n" ], "id_hash": -7133463896240499282, "content_hash": -7133463896240499282, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 2737, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 212, "source_unit": "https://translate.fedoraproject.org/api/units/2717836/?format=api", "priority": 100, "id": 2734102, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=1d00d8618e82d5ae", "url": "https://translate.fedoraproject.org/api/units/2734102/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:27.224025Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nStandard vault uses a secure mechanism to transport and\nstore the secret. The secret can only be retrieved by users\nthat have access to the vault.\n" ], "previous_source": "", "target": [ "\nУ стандартному сховищі для передавання і зберігання реєстраційних\nданих використовуються безпечні механізми. Реєстраційні дані\nможе бути отримано лише користувачами, які мають доступ\nдо сховища.\n" ], "id_hash": 3052836182810591894, "content_hash": 3052836182810591894, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 2910, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 26, "source_unit": "https://translate.fedoraproject.org/api/units/2717838/?format=api", "priority": 100, "id": 2734103, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=aa5dda5569e28296", "url": "https://translate.fedoraproject.org/api/units/2734103/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:27.242575Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nSubordinate Certificate Authorities (Sub-CAs) can be added for scoped issuance\nof X.509 certificates.\n" ], "previous_source": "", "target": [ "\nПідлеглі служби сертифікації (Sub-CA) можна додавати для обмежених під час видання областю\nсертифікатів X.509.\n" ], "id_hash": -4025746402103804958, "content_hash": -4025746402103804958, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 2964, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 13, "source_unit": "https://translate.fedoraproject.org/api/units/2717840/?format=api", "priority": 100, "id": 2734104, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=4821acfa02cbbbe2", "url": "https://translate.fedoraproject.org/api/units/2734104/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:27.256043Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nSudo (su \"do\") allows a system administrator to delegate authority to\ngive certain users (or groups of users) the ability to run some (or all)\ncommands as root or another user while providing an audit trail of the\ncommands and their arguments.\n" ], "previous_source": "", "target": [ "\nSudo (su \"do\") надає системному адміністратору змогу делегувати\nповноваження певним користувачам (або групам користувачів) на виконання\nдеяких (або усіх) команд від імені адміністратора (root) або іншого\nкористувача, зберігаючи водночас журнал виконання команд та\nаргументів.\n" ], "id_hash": 8328534917136145362, "content_hash": 8328534917136145362, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 2228, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 42, "source_unit": "https://translate.fedoraproject.org/api/units/2722424/?format=api", "priority": 100, "id": 2734105, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=f394e66173565bd2", "url": "https://translate.fedoraproject.org/api/units/2734105/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:27.270689Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nSudo Commands\n\nCommands used as building blocks for sudo\n\nEXAMPLES:\n\n Create a new command\n ipa sudocmd-add --desc='For reading log files' /usr/bin/less\n\n Remove a command\n ipa sudocmd-del /usr/bin/less\n" ], "previous_source": "", "target": [ "\nКоманди sudo\n\nКоманди, використані як будівельні блоки для sudo\n\nПРИКЛАДИ:\n\n Створення запису команди\n ipa sudocmd-add --desc='Читання файлів журналу' /usr/bin/less\n\n Вилучення команди\n ipa sudocmd-del /usr/bin/less\n" ], "id_hash": -2108216860654702479, "content_hash": -2108216860654702479, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 1286, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 27, "source_unit": "https://translate.fedoraproject.org/api/units/2722426/?format=api", "priority": 100, "id": 2734106, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=62be1bef5f2ff071", "url": "https://translate.fedoraproject.org/api/units/2734106/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:27.283984Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/uk/?format=api", "source": [ "\nSudo Commands\n\nCommands used as building blocks for sudo\n\nEXAMPLES:\n\n Create a new command\n ipa sudocmd-add --desc='For reading log files' /usr/bin/less\n\n Remove a command\n ipa sudocmd-del /usr/bin/less\n\n" ], "previous_source": "", "target": [ "\nКоманди sudo\n\nКоманди, використані як будівельні блоки для sudo\n\nПРИКЛАДИ:\n\n Створення запису команди\n ipa sudocmd-add --desc='Читання файлів журналу' /usr/bin/less\n\n Вилучення команди\n ipa sudocmd-del /usr/bin/less\n\n" ], "id_hash": 1815645661676354391, "content_hash": 1815645661676354391, "location": "", "context": "", "note": "", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 2764, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 27, "source_unit": "https://translate.fedoraproject.org/api/units/2717842/?format=api", "priority": 100, "id": 2734107, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/uk/?checksum=9932781c0e32bb57", "url": "https://translate.fedoraproject.org/api/units/2734107/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:52:27.295154Z", "last_updated": "2023-06-16T11:46:33.795393Z" } ] }