Units
Translation components API.
See the Weblate's Web API documentation for detailed description of the API.
GET /api/translations/freeipa/ipa-4-8/ru/units/?format=api&page=7
{ "count": 4657, "next": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/units/?format=api&page=8", "previous": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/units/?format=api&page=6", "results": [ { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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 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": true, "num_words": 206, "source_unit": "https://translate.fedoraproject.org/api/units/2717788/?format=api", "priority": 100, "id": 2727907, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=c628c9ee32b43f9f", "url": "https://translate.fedoraproject.org/api/units/2727907/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.093211Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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": 2727908, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=4866e231dbe77000", "url": "https://translate.fedoraproject.org/api/units/2727908/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.118463Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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С помощью разрешений можно очень точно делегировать права доступа. Разрешение представляет собой удобную для восприятия форму 389-ds ACI (правила управления доступом).\nРазрешение даёт право выполнять определённую задачу, например, добавлять пользователей, изменять группы и так далее.\n\nРазрешение не может содержать другие разрешения.\n\n* Разрешение даёт доступ для чтения, записи, добавления или удаления.\n* Привилегия объединяет схожие разрешения (например, все разрешения, которые требуются для добавления пользователя).\n* Роль даёт набор привилегий пользователям, группам, узлам или группам узлов.\n\nРазрешение состоит из нескольких разных частей:\n\n1. Имя разрешения.\n2. Цель разрешения.\n3. Права, предоставленные разрешением.\n\nПрава определяют, какие действия разрешены. Варианты прав (права могут сочетать в себе несколько вариантов):\n1. write - записать один или несколько атрибутов.\n2. read - прочитать один или несколько атрибутов.\n3. add - добавить в дерево новую запись.\n4. delete - удалить существующую запись.\n5. all - предоставляются все разрешения.\n\nПо умолчанию доступ для чтения разрешён для большинства атрибутов, поэтому потребность в использовании этого разрешения вряд ли будет возникать часто.\n\nОбратите внимание на разницу между атрибутами и записями. Разрешения являются независимыми, поэтому возможность добавить пользователя не означает возможность изменять запись добавленного пользователя.\n\nСуществует ряд разрешённых целей:\n1. type: тип объекта (пользователь, группа и так далее).\n2. memberof: участник группы или группы узлов.\n3. filter: фильтр LDAP.\n4. subtree: фильтр LDAP, определяющий часть LDAP DIT. Это супермножество цели \"type\".\n5. targetgroup: предоставление доступа для изменения определённой группы (например, предоставление прав доступа для управления участием в группе).\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": 2727909, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=3d8b0dcef49ec6f4", "url": "https://translate.fedoraproject.org/api/units/2727909/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.133247Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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С помощью разрешений можно очень точно делегировать права доступа. Разрешение представляет собой удобную для восприятия форму 389-ds ACI (правила управления доступом).\nРазрешение даёт право выполнять определённую задачу, например, добавлять пользователей, изменять группы и так далее.\n\nРазрешение не может содержать другие разрешения.\n\n* Разрешение даёт доступ для чтения, записи, добавления, удаления, чтения, поиска или сравнения.\n* Привилегия объединяет схожие разрешения (например, все разрешения, которые требуются для добавления пользователя).\n* Роль даёт набор привилегий пользователям, группам, узлам или группам узлов.\n\nРазрешение состоит из нескольких разных частей:\n\n1. Имя разрешения.\n2. Цель разрешения.\n3. Права, предоставленные разрешением.\n\nПрава определяют, какие действия разрешены. Варианты прав (права могут сочетать в себе несколько вариантов):\n1. write - записать один или несколько атрибутов.\n2. read - прочитать один или несколько атрибутов.\n3. search - поиск по одному или нескольким атрибутам.\n4. compare - сравнить один или несколько атрибутов.\n5. add - добавить в дерево новую запись.\n6. delete - удалить существующую запись.\n7. all - предоставляются все разрешения.\n\nОбратите внимание на разницу между атрибутами и записями. Разрешения являются независимыми, поэтому возможность добавить пользователя не означает возможность изменять запись добавленного пользователя.\n\nСуществует ряд разрешённых целей:\n1. subtree: DN; разрешение применяется к поддереву под этим DN.\n2. target filter: фильтр LDAP.\n3. target: DN с возможными подстановочными знаками, определяет записи, к которым применяется разрешение.\n\nКроме того, имеются следующие удобные параметры. Установка одного из них установит соответствующий атрибут (атрибуты).\n1. type: тип объекта (пользователь, группа и так далее); устанавливает поддерево и фильтр целей.\n2. memberof: применить к участникам группы; устанавливает фильтр целей.\n3. targetgroup: предоставить доступ для изменения определённой группы (например, предоставить права доступа для управления участием в группе); устанавливает цель.\n\nУправляемые разрешения\n\nРазрешения, которые по умолчанию поставляются с IPA, можно называть \"управляемыми\". Имеется заданный по умолчанию набор атрибутов, к которым они применяются, но администратор может добавлять в набор или удалять из него отдельные атрибуты.\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": true, "num_words": 405, "source_unit": "https://translate.fedoraproject.org/api/units/2727910/?format=api", "priority": 100, "id": 2727911, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=a23cbb69a1e67b24", "url": "https://translate.fedoraproject.org/api/units/2727911/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.211953Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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" ], "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": 2727912, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=5e562493d633e8b7", "url": "https://translate.fedoraproject.org/api/units/2727912/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.235478Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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-сервер. Сервер возвращает сведения о своей версии. Эти данные используются клиентом IPA для подтверждения того, что сервер доступен и принимает запросы.\n\nСервер из xmlrpc_uri in /etc/ipa/default.conf проверяется первым.\nЕсли он не отвечает, клиент пытается установить связь с любым сервером, указанным в записях SRV ldap в DNS.\n\nПРИМЕРЫ:\n\n Проверить связь с IPA-сервером:\n ipa ping\n ------------------------------------------\n IPA server version 2.1.9. API version 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 server version 2.1.9. API version 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": true, "num_words": 116, "source_unit": "https://translate.fedoraproject.org/api/units/2717796/?format=api", "priority": 100, "id": 2727913, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=97e066db498127ad", "url": "https://translate.fedoraproject.org/api/units/2727913/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.256081Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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-сервер. Сервер возвращает сведения о своей версии. Эти данные используются клиентом IPA для подтверждения того, что сервер доступен и принимает запросы.\n\nСервер из xmlrpc_uri in /etc/ipa/default.conf проверяется первым.\nЕсли он не отвечает, клиент пытается установить связь с любым сервером, указанным в записях SRV ldap в DNS.\n\nПРИМЕРЫ:\n\n Проверить связь с IPA-сервером:\n ipa ping\n ------------------------------------------\n IPA server version 2.1.9. API version 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 server version 2.1.9. API version 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": true, "num_words": 116, "source_unit": "https://translate.fedoraproject.org/api/units/2717798/?format=api", "priority": 100, "id": 2727914, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=c69c04a5c67c8f43", "url": "https://translate.fedoraproject.org/api/units/2727914/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.272481Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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Чтобы запустить этот код на легком сервере (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\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": 2727916, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=edf2cd0faa3c7d48", "url": "https://translate.fedoraproject.org/api/units/2727916/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.302178Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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Чтобы запустить этот код на легком сервере (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\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": 2727918, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=5bd996c335eb716c", "url": "https://translate.fedoraproject.org/api/units/2727918/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.338283Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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": 2727919, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=a5b558c992f6fb20", "url": "https://translate.fedoraproject.org/api/units/2727919/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.358087Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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Привилегия объединяет разрешения в логическую задачу. Разрешение предоставляет права на выполнение отдельной задачи. Для успешного выполнения некоторых операций IPA требуется несколько разрешений. Привилегия — это объединение разрешений для выполнения определённой задачи.\n\nНапример, для добавления пользователя необходимы следующие разрешения:\n * Создание новой записи пользователя\n * Сброс пароля пользователя\n * Добавление нового пользователя в группу пользователей IPA по умолчанию\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": 2727920, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=21cb4a7259916005", "url": "https://translate.fedoraproject.org/api/units/2727920/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.376219Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?format=api", "source": [ "\nProvides API introspection capabilities.\n" ], "previous_source": "", "target": [ "\nПредоставляет возможности самоанализа API.\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": 2727921, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=fa47c11390ca4756", "url": "https://translate.fedoraproject.org/api/units/2727921/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.394035Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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": 2727922, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=57768578fb3cee69", "url": "https://translate.fedoraproject.org/api/units/2727922/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.404287Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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 для выполнения аутентификации с помощью одноразового пароля krb5. Эта поддержка обеспечивает значительную гибкость при интеграции со сторонними службами аутентификации.\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": true, "num_words": 74, "source_unit": "https://translate.fedoraproject.org/api/units/2722400/?format=api", "priority": 100, "id": 2727923, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=07909d394cdf4dc2", "url": "https://translate.fedoraproject.org/api/units/2727923/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.416030Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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Дополнительные сведения доступны на страницах справочника по ipa-client-install.\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": true, "num_words": 46, "source_unit": "https://translate.fedoraproject.org/api/units/2717806/?format=api", "priority": 100, "id": 2727924, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=450a313e34de49b0", "url": "https://translate.fedoraproject.org/api/units/2727924/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.432492Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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": 2727925, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=d4ab63cc3750dff0", "url": "https://translate.fedoraproject.org/api/units/2727925/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.449253Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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Управление списком доменов, связанных с областью (realm) 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": 2727926, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=fa323849ebf9bc3c", "url": "https://translate.fedoraproject.org/api/units/2727926/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.461851Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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Управление списком доменов, связанных с областью (realm) IPA.\n\nЭтот список используется контроллерами доменов из других областей (realms), у которых установлено отношение доверия с этой областью (realm) IPA. Им необходимы сведения о том, какой запрос следует перенаправить в центр распространения ключей (KDC) этой области (realm) IPA.\n\nПри автоматическом управлении: домен автоматически добавляется в список доменов области (realm) при создании новой зоны DNS под управлением IPA. То же самое относится и к удалению.\n\nПри внешнем управлении DNS: домены, которые не управляются в DNS IPA-сервера, необходимо вручную добавить в список с помощью команды 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": 2727927, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=d8fb71069b99b166", "url": "https://translate.fedoraproject.org/api/units/2727927/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.476528Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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": 2727928, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=83291be638c723a6", "url": "https://translate.fedoraproject.org/api/units/2727928/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.495990Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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": 2727929, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=2256d293d7487d97", "url": "https://translate.fedoraproject.org/api/units/2727929/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.513181Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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 Поиск от имени пользователя 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" ], "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": true, "num_words": 153, "source_unit": "https://translate.fedoraproject.org/api/units/2717814/?format=api", "priority": 100, "id": 2727930, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=9a6f7f36c777d829", "url": "https://translate.fedoraproject.org/api/units/2727930/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.531611Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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Права определяют, какие действия разрешены. Варианты прав (права могут сочетать в себе несколько вариантов):\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": true, "num_words": 72, "source_unit": "https://translate.fedoraproject.org/api/units/2717816/?format=api", "priority": 100, "id": 2727931, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=aa051c24fcc763cf", "url": "https://translate.fedoraproject.org/api/units/2727931/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.554420Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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Роль используется для точного делегирования прав доступа. Разрешение даёт право выполнять указанные низкоуровневые задачи (добавлять пользователей, изменять группы и так далее). Привилегия содержит одно или несколько разрешений, что даёт полномочия более высокого уровня, например, администратора пользователей (useradmin). Имея привилегию useradmin, можно добавлять, удалять и изменять записи пользователей.\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 Результатом выполнения этих команд станет то, что все пользователи из группы \"junioradmin\" смогут добавлять записи пользователей, сбрасывать пароли или добавлять пользователя в группу пользователей 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": 2727932, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=bbb0d7ac95b3688f", "url": "https://translate.fedoraproject.org/api/units/2727932/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.567465Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?format=api", "source": [ "\nRoutines for constructing certificate signing requests using IPA data and\nstored templates.\n" ], "previous_source": "", "target": [ "\nПроцедуры по созданию запросов на подпись сертификатов с помощью данных IPA и сохранённых шаблонов.\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": true, "num_words": 12, "source_unit": "https://translate.fedoraproject.org/api/units/2727933/?format=api", "priority": 100, "id": 2727934, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=f42f3bbf2aba2943", "url": "https://translate.fedoraproject.org/api/units/2727934/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.597484Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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": 2727935, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=45e7cc0fff5501a9", "url": "https://translate.fedoraproject.org/api/units/2727935/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.610356Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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Узлы, группы узлов, пользователи и группы можно либо определить внутри правила, либо установить в правиле ссылку на существующее правило HBAC rule. При использовании параметра --hbacrule для selinuxusermap-find задаётся точное соответствие имени правила HBAC, поэтому будет возращена только одна запись или ноль записей.\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=server.example.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 Создать правило для определённого пользователя. Оно устанавливает для пользователя \"john\" SELinux-контекст 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 С помощью команды config-show можно вывести список, который определяет порядок применения списка пользователей SELinux, а также показать пользователя SELinux по умолчанию.\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": 2727936, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=9d1f93c998106787", "url": "https://translate.fedoraproject.org/api/units/2727936/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.621136Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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": 2727937, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=f404ee942deb4eca", "url": "https://translate.fedoraproject.org/api/units/2727937/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.635678Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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 Следует учитывать, что с помощью команды find выполняется только поиск указанного текста в наборе записей ACI; при поиске записи ACI не оцениваются по критерию применимости.\n Например, при поиске по тексту memberof=ipausers будут найдены все записи ACI, в которых memberof содержат ipausers. Но могут иметься другие записи ACI, которые применяются к участникам этой группы опосредованно.\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": true, "num_words": 92, "source_unit": "https://translate.fedoraproject.org/api/units/2717824/?format=api", "priority": 100, "id": 2727938, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=78402765c6f669a8", "url": "https://translate.fedoraproject.org/api/units/2727938/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.645075Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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С помощью разрешений самообслуживания можно очень точно делегировать разрешения. Правила или инструкции управления доступом (ACI) предоставляют разрешениям разрешение на выполнение конкретных задач, таких как добавление пользователя, изменение группы и так далее.\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 В список атрибутов необходимо включить все атрибуты, в том числе уже существующие. Добавить 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": 2727939, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=bacc8c11bb97442d", "url": "https://translate.fedoraproject.org/api/units/2727939/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.658903Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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С помощью разрешений самообслуживания можно очень точно делегировать разрешения. Правила или инструкции управления доступом (ACI) предоставляют разрешениям разрешение на выполнение конкретных задач, таких как добавление пользователя, изменение группы и так далее.\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 В список атрибутов необходимо включить все атрибуты, в том числе уже существующие. Добавить 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": 2727940, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=7e31a5c68f15ddee", "url": "https://translate.fedoraproject.org/api/units/2727940/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.680202Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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Здесь хранится значение уведомления о пароле (--pwdexpnotify), поэтому оно будет реплицировано. В текущей версии оно не используется для заблаговременного уведомления пользователей об окончании срока действия пароля.\n\nНекоторые атрибуты предоставлены в ознакомительных целях и доступны только для чтения. Среди них:\n\nОснова субъекта сертификата: настроенная основа субъекта сертификата, например O=EXAMPLE.COM. Настраивается только во время установки.\nВозможности подключаемого модуля паролей: в текущей версии он определяет дополнительные хеши, которые создаются на основе пароля (могут быть и другие условия).\n\nПри установке приоритета сопоставления пользователей SELinux, возможно, потребуется взять значение в кавычки, чтобы оно не обрабатывалось оболочкой.\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 Увеличить установленные по умолчанию ограничения времени и размера поиска IPA-сервера:\n ipa config-mod --searchtimelimit=10 --searchrecordslimit=2000\n\n Указать почтовый домен пользователей по умолчанию:\n ipa config-mod --emaildomain=example.com\n\n Включить режим миграции, чтобы сделать работоспособной команду \"ipa migrate-ds\":\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": true, "num_words": 178, "source_unit": "https://translate.fedoraproject.org/api/units/2722414/?format=api", "priority": 100, "id": 2727941, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=c6016f780dc9032a", "url": "https://translate.fedoraproject.org/api/units/2727941/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.697453Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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Здесь хранится значение уведомления о пароле (--pwdexpnotify), поэтому оно будет реплицировано. В текущей версии оно не используется для заблаговременного уведомления пользователей об окончании срока действия пароля.\n\nНекоторые атрибуты предоставлены в ознакомительных целях и доступны только для чтения. Среди них:\n\nОснова субъекта сертификата: настроенная основа субъекта сертификата, например O=EXAMPLE.COM. Настраивается только во время установки.\nВозможности подключаемого модуля паролей: в текущей версии он определяет дополнительные хеши, которые создаются на основе пароля (могут быть и другие условия).\n\nПри установке приоритета сопоставления пользователей SELinux, возможно, потребуется взять значение в кавычки, чтобы оно не обрабатывалось оболочкой.\n\nМаксимальная длина имени узла в Linux управляется параметром ядра MAXHOSTNAMELEN и по умолчанию составляет 64 символа. В некоторых других операционных системах, например, в Solaris, разрешены имена узлов длиной вплоть до 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 Увеличить установленные по умолчанию ограничения времени и размера поиска IPA-сервера:\n ipa config-mod --searchtimelimit=10 --searchrecordslimit=2000\n\n Указать почтовый домен пользователей по умолчанию:\n ipa config-mod --emaildomain=example.com\n\n Включить режим миграции, чтобы сделать работоспособной команду \"ipa migrate-ds\":\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": 2727943, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=07d47b12b980c069", "url": "https://translate.fedoraproject.org/api/units/2727943/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.744433Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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Управление правилами, с помощью которых можно ограничить делегирование учётных данных таким образом, что служба сможет выполнять олицетворение пользователя при обмене данными с другой службой без необходимости для пользователя самом деле перенаправлять билет для получения билета (TGT). Такой метод делегирования учётных данных значительно лучше, так как предотвращает раскрытие краткосрочного секрета пользователя.\n\nВ соответствии с соглашением об именовании к имени соответствующего правила добавляется слово \"target\" или \"targets\". Такая схема имён не является обязательной, но она помогает концептуально связать правила и их назначения.\n\nПравило состоит из двух компонентов:\n - Список целей (назначений), к которым применяется правило\n - Список memberPrincipals, которым разрешено делегирование для этих целей \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 может получать билет для получения билета для службы ldap от имени связанного пользователя.\n\nНастоятельно не рекомендуется изменять делегирования, которые поставляются с IPA, ipa-http-delegation и его цели ipa-cifs-delegation-targets и Ipa-ldap-delegation-targets. Неправильная настройка может привести к потере возможности делегирования, что повлечет неработоспособность всей системы.\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": 2727944, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=3d01645eaffc3a90", "url": "https://translate.fedoraproject.org/api/units/2727944/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.772478Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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 — это служба, которая выполняется на узле. В записи службы IPA могут храниться данные учётной записи Kerberos, SSL-сертификата или оба набора данных.\n\nСлужбой IPA можно управлять непосредственно с компьютера, если системе этого компьютера предоставлены соответствующие права доступа. Это касается даже компьютеров, отличных от тех, с которыми связана эта служба. Например, запрос SSL-сертификата с помощью учётных данных учётной записи службы узла. Чтобы управлять службой с помощью учётных данных узла, следует запустить команду kinit от имени узла:\n\n # kinit -kt /etc/krb5.keytab host/ipa.example.com@EXAMPLE.COM\n\nДобавление службы IPA позволяет связанной службе запрашивать SSL-сертификаты и таблицы ключей, но создание самих запросов является отдельным шагом: соответствующие данные не создаются в результате простого добавления службы.\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. В текущей версии соответствующий код в ядре Linux может работать только с билетами Kerberos, размер которых не превышает максимально заданного. Так как данные PAC могут быть довольно объёмными, для служб NFS рекомендуется установить --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" ], "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": 2727945, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=89c9eed54ab17be6", "url": "https://translate.fedoraproject.org/api/units/2727945/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.792047Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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 — это служба, которая выполняется на узле. В записи службы IPA могут храниться данные учётной записи Kerberos, SSL-сертификата или оба набора данных.\n\nСлужбой IPA можно управлять непосредственно с компьютера, если системе этого компьютера предоставлены соответствующие права доступа. Это касается даже компьютеров, отличных от тех, с которыми связана эта служба. Например, запрос SSL-сертификата с помощью учётных данных учётной записи службы узла. Чтобы управлять службой с помощью учётных данных узла, следует запустить команду kinit от имени узла:\n\n # kinit -kt /etc/krb5.keytab host/ipa.example.com@EXAMPLE.COM\n\nДобавление службы IPA позволяет связанной службе запрашивать SSL-сертификаты и таблицы ключей, но создание самих запросов является отдельным шагом: соответствующие данные не создаются в результате простого добавления службы.\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. В текущей версии соответствующий код в ядре Linux может работать только с билетами Kerberos, размер которых не превышает максимально заданного. Так как данные PAC могут быть довольно объёмными, для служб NFS рекомендуется установить --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": 2727947, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=0d6adeb0608eac69", "url": "https://translate.fedoraproject.org/api/units/2727947/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.837437Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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 — это служба, которая выполняется на узле. В записи службы IPA могут храниться данные учётной записи Kerberos, SSL-сертификата или оба набора данных.\n\nСлужбой IPA можно управлять непосредственно с компьютера, если системе этого компьютера предоставлены соответствующие права доступа. Это касается даже компьютеров, отличных от тех, с которыми связана эта служба. Например, запрос SSL-сертификата с помощью учётных данных учётной записи службы узла. Чтобы управлять службой с помощью учётных данных узла, следует запустить команду kinit от имени узла:\n\n # kinit -kt /etc/krb5.keytab host/ipa.example.com@EXAMPLE.COM\n\nДобавление службы IPA позволяет связанной службе запрашивать SSL-сертификаты и таблицы ключей, но создание самих запросов является отдельным шагом: соответствующие данные не создаются в результате простого добавления службы.\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": 2727948, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=0d82f59719eaa92b", "url": "https://translate.fedoraproject.org/api/units/2727948/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.861353Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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": 2727950, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=538c7beae6ecb334", "url": "https://translate.fedoraproject.org/api/units/2727950/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:00.906829Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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* Отсутствие привязки к конкретным веб-серверам или браузерам. Обеспечение интеграции с выбранной моделью WSGI.\n\nПроблемы\n======\n\nCookie-файлы\n-------\n\nБольшинство реализаций сеансов основано на использовании cookie-файлов. С этим связаны определённые проблемы.\n\n* Пользователь может отключить использование cookie-файлов.\n\n* Хранение cookie-файлов на стороне пользователя не является безопасным. Эту проблему можно исправить установкой флажков, обозначающих использование cookie-файлов только для HTTP-подключений с SSL-защитой, для определённых сетевых ресурсов, и ограничение срока действия cookie-файлов сроком работы сеанса. В большинстве современных браузеров эти настройки устанавливаются принудительно.\n\nГде хранить данные сеанса?\n----------------------------\n\nДанные сеанса можно хранить на стороне клиента или на стороне сервера. Хранение данных сеанса на стороне клиента решает проблему доступности данных сеанса при обслуживании запросов независимыми веб-серверами, потому что данные сеанса отправляются вместе с запросом. Но имеются ограничения размера данных. Хранение данных сеанса на стороне клиента также ведёт к опасности несанкционированного доступа к конфиденциальным данным, но эту проблему можно решить путём шифрования данных сеанса таким образом, чтобы их мог расшифровать только сервер.\n\nБолее распространённый подход: привязать данные сеанса к уникальному имени, идентификатору сеанса. Идентификатор сеанса передаётся клиенту и данные сеанса сопоставляются идентификатору сеанса в банке ассоциативных данных на сервере. Сервер получает данные сеанса путём использования идентификатора сеанса при получении запроса. Таким образом исключается возможность несанкционированного доступа к конфиденциальным данным на стороне клиента и снимается вопрос ограничения размера данных. Но возникает проблема доступности данных сеанса при обслуживании запросов более чем одним серверным процессом.\n\nДоступность данных сеанса для нескольких процессов\n---------------------------------------\n\nApache (и другие веб-серверы) разветвляют дочерние процессы для параллельной обработки запросов. Кроме того, веб-серверы могут быть развёрнуты на ферме, где путём циклического перебора выполняется балансировка нагрузки между разными узлами. В обоих случаях данные сеанса нельзя хранить в памяти серверного процесса, потому что они не будут доступны другим процессам: либо таким же дочерним процессам главного серверного процесса, либо серверным процессам на определённых узлах.\n\nОбычно эта проблема решается путём хранения данных сеанса в базе данных SQL. Когда серверный процесс получает запрос, содержащий идентификатор сеанса в своих данных cookie, этот идентификатор сеанса используется для создания запроса к базе данных SQL, а результат запроса приобщается к самому запросу в ходе его движения по конвейеру обработки запросов. Естественно, это влечёт проблемы обеспечения непротиворечивости данных.\n\nВ IPA нежелательно внедрение зависимости от базы данных SQL, этого рекомендуется избегать.\n\nДанные сеанса можно предоставить в совместное использование независимых процессов, если хранить их в файлах.\n\nВ последнее время всё чаще используется альтернативное решение: использование сервера кэширования на основе быстрой памяти. Данные хранятся в памяти одного процесса, по ним можно отправлять запросы и их можно изменять с помощью простого протокола с использованием стандартных механизмов работы с сокетами. Примером является memcached. Обычно это решение используется для оптимизации обработки SQL-запросов путём хранения результатов SQL-запросов в общем кэше памяти, что позволяет избежать потребления значительного количества ресурсов при работе с базой данных SQL. Но кэш памяти имеет преимущества также и в средах без SQL.\n\nВозможные реализации для использования в IPA\n=======================================\n\nСеансы Apache\n---------------\n\nВ Apache версии 2.3 реализована сеансовая поддержка с помощью следующих модулей:\n\n mod_session\n Общая сеансовая поддержка на основе cookie-файлов.\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 Шифрует данные сеанса для обеспечения безопасности. Ключ шифрования является общим параметром конфигурации, виден всем процессам Apache и хранится в файле конфигурации. \n\n Подробнее: http://httpd.apache.org/docs/2.3/mod/mod_session_crypto.html\n\n mod_session_dbd\n Сохраняет данные сеанса в базе данных SQL, что позволяет нескольким процессам осуществлять доступ к одним и тем же данным сеанса и совместно использовать их.\n\n Подробнее: http://httpd.apache.org/docs/2.3/mod/mod_session_dbd.html\n\nПроблемы, связанные с сеансами Apache\n~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nХотя в Apache реализована общая сеансовая поддержка и предпочтительно использование именно веб-сервера Apache, он создаёт проблемы в работе с IPA.\n\n * Сеансовая поддержка доступна только в httpd >= 2.3. На момент написания данного текста существует только бета-релиз из основной ветки разработки. Текущей версией в нашем дистрибутиве является httpd 2.2. То же касается и других дистрибутивов.\n\n * Мы могли бы создать пакеты и поставлять модули для работы с сеансами как временные пакеты в средах с httpd 2.2, но это будет иметь такие последствия:\n\n - Придётся выполнять обратное портирование кода, в httpd 2.3 немного изменился API по сравнению с httpd 2.2. Обратное портирование не так уж сложно выполнить, проверка концепции была реализована.\n\n - Нам пришлось бы паковать и сопровождать специальный пакет Apache. Это работа по сопровождению кода и его упаковке для дистрибутивов. И того, и другого желательно было бы избежать.\n\n * Концепция построения модулей для работы с сеансами Apache такова, что управлять этими модулями можно только из других модулей Apache. Возможности потребителей данных сеанса по управлению данными чрезмерно упрощены, ограничены и статичны во время обработки запроса. Обработчики запросов, не являющиеся собственными модулями Apache (например, IPA через WSGI), могут только изучать данные сеанса с помощью заголовков запросов и сбрасывать эти данные в заголовках ответов.\n\n * Общий доступ к данным сеанса доступен только с помощью SQL.\n\nВпрочем, использование модулей для работы с сеансами Apache 2.3 предоставило бы нам надёжную сеансовую поддержку, реализованную на языке C на основе стандартизированных и широко используемых интерфейсов Apache.\n\nПлатформы для разработки веб-приложений на языке Python \n---------------------\n\nПрактически все платформы для разработки веб-приложений на Python поддерживают сеансы на основе cookie-файлов, например, Django, Twisted, Zope, Turbogears и так далее. На ранних этапах разработки IPA мы решили не использовать эти платформы. Попытка заимствовать только часть этих платформ, чтобы просто получить сеансовую поддержку, привела бы к проблемам, так как код не будет работать вне соответствующей платформы.\n\nСеансы, реализованные средствами IPA\n------------------------\n\nСначала нам казалось, что проще всего будет воспользоваться готовой сеансовой поддержкой; скорее всего, той, которая реализована в Apache. Впрочем, оказалось, что в собственных пакетах Python и других стандартных пакетах имеется достаточное количество базовых модульных компонентов, которые позволяют выполнить указанные выше требования при сравнительно незначительных затратах на реализацию. Поскольку мы используем имеющиеся компоненты, сложности с реализацией должны быть нивелированы использованием компонентов, которые уже проверены и поддерживаются сообществом. Это довольно взвешенная стратегия.\n\nПредлагаемое решение\n=================\n\nНаш интерфейс веб-сервера работает с помощью WSGI (стандарт взаимодействия между Python-программой и самим веб-сервером), который выполняет обратный вызов для каждого запроса и передаёт нам контекст среды для запроса. В дальнейшем мы будем называть обратной вызов WSGI \"application()\"; это правильное название в пределах синтаксиса WSGI. \n\nОбработку общих данных сеансов будет осуществлять memcached. Мы будем создавать на каждом серверном узле один экземпляр memcached, предназначенный исключительно для IPA. Обмен данными с memcached будет осуществляться с помощью сокета UNIX, расположенного в файловой системе по адресу /var/run/ipa_memcached. Сокет будет защищён правами доступа файловой системы и, если нужно, правилом SELinux.\n\nВ application() мы изучаем cookie-файлы запроса и, если имеется cookie-файл сеанса IPA с идентификатором сеанса, получаем данные сеанса с нашего экземпляра memcached. \n\nДанные сеанса будут являться словарём (dict) Python. Компоненты IPA будут читать или записывать свои сведения о сеансе путём использования предварительно согласованного имени (например, ключа) в dict. Это очень гибкая система, соответствующая тому, как мы передаём данные в большинстве частей IPA.\n\nЕсли данные сеанса недоступны, будет создан пустой словарь данных сеанса.\n\nКак эти данные сеанса перемещаются вместе с запросом по конвейеру IPA? В IPA мы используем HTTP-запрос/-ответ для реализации RPC. В\napplication() мы преобразуем запрос в вызов процедуры, передавая её аргументы, полученные из HTTP-запроса. Переданные параметры зависят от конкретного вызванного метода RPC. Контекст, в котором исполняется вызов RPC, не передаётся как параметр RPC. \n\nКаким образом данные сеанса, представляющие собой контекстную информацию, привязываются к запросу и, следовательно, вызову RPC?\n\nВ IPA при подготовке вызова RPC из запроса мы признаём, что серийная обработка будет выполняться только одним потоком Python. Для каждого потока выделяется локальный по отношению к потоку словарь, который называется \"context\". Этот контекстный словарь очищается между запросами (например, вызовами метода RPC). Соответствующий потоку контекстный словарь заполняется данными во время срока работы запроса и используется в качестве глобальной структуры данных, уникальной для запроса и доступной компонентам IPA для чтения и записи при гарантии уникальности данных для текущего запроса и/или вызова метода.\n\nСловарь данных сеанса записывается в контекстный словарь с сеансовым ключом до начала выполнения метода RPC. Поэтому любой компонент IPA может выполнить чтение и запись данных путём доступа к \"context.session\".\n\nПо завершении выполнения метода RPC данные сеанса, привязанные к запросу/методу, извлекаются из контекста и записываются обратно в экземпляр memcached. Идентификатор сеанса указывается в отправленном клиенту ответе, в заголовке \"Set-Cookie\", вместе с флажками, управляющими его использованием.\n\nПроблемы и подробности\n------------------\n\nКод IPA не может зависеть от факта наличия данных сеанса, но он всегда должен обновлять данные сеанса из расчёта на их доступность в будущем. Данные сеанса могут быть недоступны по следующим причинам:\n\n * Это первый запрос от пользователя, данные сеанса ещё не созданы.\n\n * На стороне пользователя отключены cookie-файлы.\n\n * Данные сеанса могли быть сброшены. memcached работает с фиксированным выделением памяти и очищает наиболее давно использовавшиеся записи; как и любой другой кэш, он не гарантирует сохраняемость.\n\n Кроме того, мы можем намеренно сделать данные сеанса недействительными или удалить их (об этом далее).\n\nУправление сookie-файлами выполняется с помощью стандартного модуля Cookie на Python.\n\nСookie-файлы сеанса будут существовать столько, сколько длится сеанс браузера. Они будут помечены таким образом, чтобы браузер возвращал идентификатор сессии только для HTTP-запросов с SSL-защитой. Они не будут видны для Javascript в браузере.\n\nИдентификаторы сеанса будут создаваться с помощью 48-битных случайных данных и преобразовываться в 12 шестнадцатиричных цифр. Вновь создаваемые идентификаторы сеанса будут проверяться на предыдущее существование, чтобы избежать маловероятного случая повтора случайного числа.\n\nmemcached будет работать значительно быстрее, чем основанное на хранении данных в SQL или файлах решение. Коммуникация эффективно выполняется через канал (сокет UNIX) с помощью очень простого протокола, а данные полностью содержатся в памяти процесса. Также memcached легко масштабировать; просто добавить дополнительные процессы memcached и распределить нагрузку между ними. На данный момент мы не видим необходимости в использовании этой возможности.\n\nУ модуля memcached на Python есть удобная особенность: когда элемент данных записывается в кэш, это выполняется с помощью стандартной сериализации Python (сериализация представляет собой стандартный механизм Python для упаковки и распаковки объектов Python). В целях обеспечения соответствия применяемым нами подходам к обработке данных: записанный в кэш объект будет являться словарём. Код сериализации будет рекурсивно обрабатывать вложенные объекты в словаре. Использование стандартных структур данных Python обеспечивает гибкость при хранении и получении наших данных сеанса без необходимости написания и отладки кода для упаковки и распаковки данных (что понадобилось бы при использовании другого механизма хранения). Это большой плюс реализации. Конечно, следует разумно подходить к выбору того, что следует записывать в кэш сеанса, учитывая, что процессы осуществляют общий доступ к данным и что их размер не должен быть слишком велик (настраиваемый параметр).\n\nМы можем установить срок действия записей memcached. Это можно сделать в целях принудительного периодического обновления данных сеанса. Например, мы нам может быть нужно, чтобы клиент периодически предоставлял свежие учётные данные, даже если хранящиеся в кэше учётные данные ещё действительны.\n\nМы можем явно удалить данные сеанса, если по какой-либо причины считаем их устаревшими, недействительными или скомпрометированными.\n\nПроцесс memcached также предоставляет нам определённые возможности по предотвращению состояния гонки между разными процессами, использующими кэш. Например, можно проверить, была ли запись изменена с момента последнего прочтения, или использовать семантику CAS\n(Check And Set (проверить и установить)). Что именно следует защитить в целях обеспечения согласованности кэша, вероятно, придётся определять по мере использования сеансовой поддержки и добавления разных элементов данных в кэш. Это сильно зависит от данных и контекста. К счастью, операции memcached являются атомарными.\n\nУправление процессом memcached \n---------------------------------\n\nНам нужен механизм запуска процесса memcached и обеспечения его безопасности (чтобы доступ к процессу был только у компонентов IPA).\n\nХотя memcached поставляется с файлами блоков initscript и systemd, они предназначены для экземпляров универсального типа. А нам нужен экземпляр memcached, предназначенный исключительно для использования с IPA. Чтобы достичь этой цели, нам следовало бы установить файл блока systemd или SysV initscript для управления предназначенной для IPA службой memcached. Команду ipactl было бы необходимо расширить, включив сведения об этой дополнительной службе. Возможности cgroup блока systemd предоставили бы нам дополнительные механизмы для интеграции службы memcached IPA в большую группу процессов IPA.\n\nЗащита данных memcached выполнялась бы с помощью разрешений файлов (и, если нужно, политики SELinux) на сокете домена Unix. Хотя последние реализации memcached поддерживают аутентификацию с помощью SASL, это делает работу менее производительной и более сложной, что неоправдано, когда кэш предназначается для использования только нами и доступ к нему управляется механизмами ОС. \n\nОбычно защита управляющих программ выполняется путём назначения им системного идентификатора uid и/или идентификатора группы gid. Управляющая программа, запущенная с правами суперпользователя (\"root\") утратит свои привилегии, приняв назначенный ей эффективный uid:gid. ОС управляет доступом к файловой системе с помощью эффективного идентификатора, на основе которого также можно создать политику SELinux. Таким образом, memcached на сокете UNIX был бы защищён наличием владельца (определённого системного пользователя) и/или участием в ограниченной системной группе (если на время забыть о SELinux).\n\nК сожалению, сейчас у нас нет идентификатора uid для IPA, с которым бы работали наши процессы, а также нет системной группы IPA. IPA не управляет набором связанных процессов (управляющие программы), исторически сложилось, что каждому из них назначается свой собственный uid. Когда эти несвязанные процессы общаются, они взаимно аутентифицируются через другие механизмы. Мы редко использовали объекты файловой системы с общим доступом через идентификаторы. Когда файловые объекты создаются, им обычно назначается идентификатор управляющей программы, которой требуется доступ к объекту, и другие управляющие программы не осуществляют к ним доступ, или они имеют идентификатор \"root\".\n\nКогда наше приложение WSGI выполняется в Apache, оно выполняется как управляющая программа WSGI. Это означает, что при запуске Apache она отделяет процессы WSGI и позволяет нам не зависеть от других процессов Apache. Когда WSGI выполняется в этом режиме, можно установить uid:gid ведущего процесса WSGI, но на данный момент мы не используем эту возможность. WSGI также может выполняться в других режимах, но только в режиме управляющей программы можно установить uid:gid независимо от остального Apache. Всем процессам, которые запускает Apache, можно установить общий uid:gid, указанный в глобальной конфигурации Apache, по умолчанию это: apache:apache. Теперь наш код IPA выполняется как apache:apache.\n\nЧтобы обеспечить защиту memcached на сокете UNIX, мы можем выбрать один из следующих двух вариантов:\n\n1. Назначить для него uid:gid apache:apache. Это ограничит доступ к кэшу только процессами, выполняющимися под httpd. Это обеспечит некоторую защиту, но является далеко не идеальным решением. Любой выполняемый на веб-сервере код потенциально может получить доступ к нашему кэшу. Сложно управлять тем, что выполняется на веб-сервере, и администраторы могут не понимать последствий настройки httpd для обслуживания других вещей кроме IPA.\n\n2. Создать uid:gid специально для IPA, например: ipa:ipa. Затем настроить наше приложение WSGI application для выполнения в качестве ipa:ipa пользователя и группы. Мы также настроим наш экземпляр memcached для выполнения в качестве ipa:ipa пользователя и группы. При такой конфигурации мы полностью защищены, чтение и запись в memcached на сокете UNIX может выполнять только наш код WSGI.\n\nНо при конвертации нашего кода для выполнения отличным от apache:apache образом могут возникнуть непредвиденные проблемы. Необходимы исследования и тестирование. \n\nIPA зависит от других системных управляющих программ, в частности, от сервера каталогов (Directory Server (ds)) и сервера сертификатов (Certificate Server (cs)). На данный момент мы настраиваем ds для выполнения под dirsrv:dirsrv пользователя и группы, это созданный нами идентификатор. Мы разрешаем cs использовать установленный по умолчанию идентификатор pkiuser:pkiuser пользователя и группы. Должны ли другие работающие совместно управляющие службы также выполняться под общими идентификаторами ipa:ipa пользователя и группы? На первый взгляд объединение всех идентификаторов процессов под общим идентификатором пользователя и группы IPA кажется удачным решением. Но эти другие процессы не зависят от разрешений пользователя и группы при работе с внешними агентами, процессами и так далее. Они, скорее, предназначены для того, чтобы использоваться в качестве отдельных сетевых служб, которые выполняют аутентификацию своих клиентов с помощью других механизмов. Они зависят от разрешений пользователя и группы при управлении своими собственными объектами файловой системы. Если пользователь и / или группа ipa были скомпрометированы или под идентификатором ipa был выполнен вредоносный код, то преимущество заключается в \"отгораживании\" работающих совместно процессов под их собственными идентификаторами; это обеспечивает дополнительную защиту. (Обратите внимание, что эти работающие совместно управляющие программы могут даже не находиться на одном и том же узле; в таком случае проблема становится неактуальной.)\n\nПоведение сокета UNIX (ldapi) по отношению к серверу каталогов:\n\n * Владелец сокета: root:root\n\n * Разрешения сокета: 0666\n\n * При подключении с помощью ldapi необходимо аутентифицироваться так же, как и при использовании сокета TCP, исключая следующие случаи:\n\n * Если включена функция autobind, доступна установка uid:gid с помощью\n SO_PEERCRED и uid:gid можно найти в наборе пользователей, известных серверу каталогов, то это подключение будет привязано как такой пользователь.\n\n * В ином случае будет выполнена анонимная привязка.\n\nПоведение memcached на сокете UNIX:\n\n * memcached можно вызвать аргументом пользователя, группа может быть не указана. Эффективный uid — это uid аргумента пользователя, а эффективный gid — это основная группа пользователя, назовём это так: euid:egid\n\n * Владелец сокета: euid:egid\n\n * Разрешения сокета по умолчанию: 0700, но это можно изменить аргументом командной строки -a mask (устанавливает umask (по умолчанию 0700)).\n\nОбзор аутентификации в IPA\n=================================\n\nЗдесь приведено описание текущей реализации аутентификации и того, как мы планируем повысить производительность аутентификации. Начнём с определений.\n\nИмеется 4 основных участника:\n\n 1. клиент\n 2. mod_auth_kerb (в процессе Apache)\n 3. wsgi handler (в процессе wsgi python IPA)\n 4. ds (сервер каталогов)\n\nИмеется несколько ресурсов:\n\n 1. /ipa/ui (незащищённое, статические ресурсы веб-интерфейса)\n 2. /ipa/xml (защищённое, xmlrpc RPC используется клиентами командной строки)\n 3. /ipa/json (защищённое, json RPC используется javascript в веб-интерфейсе)\n 4. ds (защищённое, wsgi действует в качестве прокси, наш LDAP-сервер)\n\nТекущая модель\n-------------\n\nЗдесь приведено описание работы нашей существующей системы с веб-интерфейсом.\n\n 1. Клиент запрашивает /ipa/ui, это незащищённое, статическое соединение, которое не содержит конфиденциальную информацию. Apache отвечает с помощью html и\n javascript. javascript запрашивает /ipa/json.\n\n 2. Клиент отправляет запрос типа post на /ipa/json.\n\n 3. mod_auth_kerb настроен для защиты /ipa/json, отвечает 401\n authenticate negotiate.\n\n 4. Клиент выполняет повторную отправку вместе с учётными данными\n\n 5. mod_auth_kerb проверяет учётные данные\n\n a. если они недействительны, отвечает 403 access denied (остановка)\n\n b. если они действительны, создаёт временный кэш учётных данных, добавляет KRB5CCNAME в заголовки запроса\n\n 6. Запрос передаётся обработчику wsgi\n\n a. проверяет запрос: должны иметься KRB5CCNAME, источник ссылки и так далее\n\n b. кэш учётных данных сохраняется и используется для привязки к серверу каталогов\n\n c. направляет в указанный обработчик RPC\n\n 7. Обработчик wsgi отвечает клиенту\n\nПредлагаемая оптимизация на основе сеансов\n---------------------------------------\n\nКруговое согласование и проверка учётных данных на этапах 3, 4, 5 требовательны к ресурсам. Эту проблему можно решить, если кэшировать учётные данные клиента. При работе с сеансами клиента можно хранить учётные данные клиента в сеансе, связанном с клиентом.\n\nНесколько замечаний о реализации сеансов.\n\n * они основаны на cookie-файлах сеанса, поэтому использование сookie-файлов должно быть включено.\n\n * cookie-файл сеанса является защищённым, передаётся по безопасным соединениям и только нашему ресурсу URL-адреса, никогда не виден для javascript клиента и так далее.\n\n * у cookie-файла сеанса есть идентификатор сеанса, который обработчик wsgi использует для получения данных сеанса клиента из общего многозадачного кэша.\n\nИзменения защиты ресурсов Apache\n---------------------------------------\n\n * Ресурс /ipa/json больше не защищён mod_auth_kerb. Это необходимо, чтобы избежать расхода ресурсов на согласование на приведённых выше этапах 3, 4, 5. Вместо этого ресурс /ipa/json будет защищён в нашем обработчике wsgi с помощью cookie-файла сеанса.\n\n * Появляется новый защищенный универсальный код ресурса (URI), /ipa/login. Этот ресурс не обслуживает данные и используется исключительно для аутентификации.\n\nНовая последовательность:\n\n 1. Клиент запрашивает /ipa/ui, это незащищённое соединение. Apache отвечает с помощью\n html и javascript. javascript запрашивает /ipa/json.\n\n 2. Клиент отправляет запрос типа post на /ipa/json, это незащищённое соединение.\n\n 3. Обработчик wsgi получает данные сеанса из cookie-файла сеанса.\n\n a. если кэш учётных данных присутствует в данных сеанса и действителен\n\n - выполняется дальнейшая проверка запроса\n\n - устанавливается кэш учётных данных для привязки к серверу каталогов\n\n - запрос направляется на обработчик RPC\n\n - обработчик wsgi в итоге отвечает клиенту\n\n b. если кэш учётных данных не присутствует или недействителен, обработка продолжается...\n\n 4. обработчик wsgi отвечает 401 Unauthorized\n\n 5. клиент отправляет запрос на /ipa/login для получения учётных данных сеанса\n\n 6. mod_auth_kerb отвечает 401 negotiate на /ipa/login\n\n 7. клиент отправляет учётные данные на /ipa/login\n\n 8. mod_auth_kerb проверяет учётные данные\n\n a. если они действительны\n\n - mod_auth_kerb разрешает доступ на /ipa/login. Вызывается обработчик wsgi, который выполняет следующее:\n\n * устанавливает сеанс для клиента\n\n * получает кэш учётных данных из KRB5CCNAME и хранит его\n\n b. если они недействительны\n\n - mod_auth_kerb отправляет 403 access denied (обработка останавливается)\n\n 9. клиент снова отправляет те же самые данные на /ipa/json, включая cookie-файл сеанса. Обработка повторно запускается с этапа 2, и, так как данные сеанса теперь содержат действительный кэш учётных данных, выполняется этап 3a, клиенту отправляется сообщение об успешном выполнении.\n\nКлиент командной строки, использующий xmlrpc\n--------------------------------\n\nВыше приведено описание веб-интерфейса, использующего механизм json RPC. Средства командной строки IPA используют механизм xmlrpc RPC на том же самом HTTP-сервере. Доступ к xmlrpc осуществляется через URI /ipa/xml. У json и xmlrpc одинаковые API, они отличаются только тем, как упаковываются и распаковываются их вызовы процедур.\n\nПри новой схеме /ipa/xml всегда остаётся защищённым Kerberos. mod_auth_kerb Apache продолжит запрашивать у клиента действительные учётные данные Kerberos.\n\nКогда обработчик WSGI направляет запрос на /ipa/xml, из переменной среды KRB5CCNAME, предоставленной модулем mod_auth_kerb, извлекаются учётные данные Kerberos. Всё остальное не меняется.\n\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": 2727952, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=c91794fce22b841e", "url": "https://translate.fedoraproject.org/api/units/2727952/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:01.002235Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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Политика паролей IPA управляет частотой смены пароля, требованиями к надёжности пароля и размером журнала паролей.\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": true, "num_words": 84, "source_unit": "https://translate.fedoraproject.org/api/units/2717834/?format=api", "priority": 100, "id": 2727953, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=ef07a8be15f6680d", "url": "https://translate.fedoraproject.org/api/units/2727953/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:01.052505Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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Имитация использования управления доступом на основе узла\n\nПравила HBAC управляют тем, кто, на каких узлах и из каких узлов сможет получать доступ к определённым службам. Вы можете воспользоваться HBAC для определения тех пользователей и групп, которые будут иметь доступ к определённой службе или группе служб на целевом узле. \n\nТак как применение правил HBAC подразумевает использование рабочей среды, этот подключаемый модуль предназначен для обеспечения имитации оценки правил HBAC при отсутствии доступа к рабочей среде.\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 Если указан параметр --enabled, добавить все включённые правила HBAC к имитации.\n\n Если указан параметр --disabled, добавить все отключённые правила HBAC к имитации.\n\n Если указан параметр --nodetail, не возвращать данные о соответствующих или не соответствующих правилах.\n\n Если одновременно указаны параметры --rules и --enabled, выполнить имитацию --rules _и_\n всех включённых правил IPA.\n\n Если не указан параметр --rules, выполнить имитацию всех включённых правил IPA.\n По умолчанию в IPA имеется общее ограничение количества извлекаемых записей, его можно изменить с помощью параметра --sizelimit.\n\n Если указан параметр --srchost, он будет проигнорирован. Он сохранён только для обеспечения совместимости.\n\nПРИМЕРЫ:\n\n 1. Использовать все включённые правила HBAC в базе данных IPA:\n $ ipa hbactest --user=a1a --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": true, "num_words": 424, "source_unit": "https://translate.fedoraproject.org/api/units/2727954/?format=api", "priority": 100, "id": 2727955, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=e144aa96a7e72360", "url": "https://translate.fedoraproject.org/api/units/2727955/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:01.098465Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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Имитация использования управления доступом на основе узла\n\nПравила HBAC управляют тем, кто и на каких узлах сможет получать доступ к определённым службам. Вы можете воспользоваться HBAC для определения тех пользователей и групп, которые будут иметь доступ к определённой службе или группе служб на целевом узле. \n\nТак как применение правил HBAC подразумевает использование рабочей среды, этот подключаемый модуль предназначен для обеспечения имитации оценки правил HBAC при отсутствии доступа к рабочей среде.\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 Если указан параметр --enabled, добавить все включённые правила HBAC к имитации.\n\n Если указан параметр --disabled, добавить все отключённые правила HBAC к имитации.\n\n Если указан параметр --nodetail, не возвращать данные о соответствующих или не соответствующих правилах.\n\n Если одновременно указаны параметры --rules и --enabled, выполнить имитацию --rules _и_\n всех включённых правил IPA.\n\n Если не указан параметр --rules, выполнить имитацию всех включённых правил IPA.\n По умолчанию в IPA имеется общее ограничение количества извлекаемых записей, его можно изменить с помощью параметра --sizelimit.\n\n ПРИМЕРЫ:\n\n 1. Использовать все включённые правила HBAC в базе данных IPA:\n $ ipa hbactest --user=a1a --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 --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 также применяются к пользователям, которые выполняют доступ к ресурсам IPA из доверенного домена. Пользователи и группы доверенного домена (и их SID) затем могут быть привязаны к внешним группам, которые могут быть участниками POSIX-групп в IPA. Такие привязки можно использовать в правилах HBAC, тем самым разрешая доступ к ресурсам, которые защищены системой HBAC.\n\nПодключаемый модуль hbactest позволяет проверять доступ как для локальных пользователей IPA, так и для пользователей из доверенных доменов, как с полным именем пользователя, так и по SID пользователей. В таких именах пользователей должен быть указан доверенный домен в краткой форме (DOMAIN\\Administrator) или имя учётной записи пользователя (UPN), Administrator@ad.test.\n\nОбратите внимание, что выполнять hbactest с аргументом пользователя доверенного домена в параметре --user могут только участники группы \"trust admins\".\n\nПРИМЕРЫ:\n\n 1. Проверить, соответствует ли пользователь из доверенного домена, указанный по краткому имени, какому-либо правилу:\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 $ ipa hbactest --user 'Administrator@domain.com' --host `hostname` --service sshd\n --------------------\n Доступ предоставлен: Да\n --------------------\n Соответствующие правила: allow_all\n Соответствующие правила: can_login\n\n 3. Проверить, соответствует ли пользователь из доверенного домена, указанный по SID, какому-либо правилу:\n\n $ ipa hbactest --user S-1-5-21-3035198329-144811719-1378114514-500 --host `hostname` --service sshd\n --------------------\n Доступ предоставлен: Да\n --------------------\n Соответствующие правила: allow_all\n Соответствующие правила: can_login\n\n 4. Проверить, соответствует ли другой пользователь из доверенного домена, указанный по SID, какому-либо правилу:\n\n $ ipa hbactest --user S-1-5-21-3035198329-144811719-1378114514-1203 --host `hostname` --service sshd\n --------------------\n Доступ предоставлен: Да\n --------------------\n Соответствующие правила: allow_all\n Несоответствующие правила: can_login\n\n 5. Проверить, соответствует ли другой пользователь из доверенного домена, указанный по краткому имени, какому-либо правилу:\n\n $ ipa hbactest --user 'DOMAIN\\Otheruser' --host `hostname` --service sshd\n --------------------\n Доступ предоставлен: Да\n --------------------\n Соответствующие правила: allow_all\n Несоответствующие правила: can_login\n\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": 2727957, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=c541bd61406412d7", "url": "https://translate.fedoraproject.org/api/units/2727957/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:01.162779Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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Имитация использования управления доступом на основе узла\n\nПравила HBAC управляют тем, кто и на каких узлах сможет получать доступ к определённым службам. Вы можете воспользоваться HBAC для определения тех пользователей и групп, которые будут иметь доступ к определённой службе или группе служб на целевом узле. \n\nТак как применение правил HBAC подразумевает использование рабочей среды, этот подключаемый модуль предназначен для обеспечения имитации оценки правил HBAC при отсутствии доступа к рабочей среде.\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 Если указан параметр --enabled, добавить все включённые правила HBAC к имитации.\n\n Если указан параметр --disabled, добавить все отключённые правила HBAC к имитации.\n\n Если указан параметр --nodetail, не возвращать данные о соответствующих или не соответствующих правилах.\n\n Если одновременно указаны параметры --rules и --enabled, выполнить имитацию --rules _и_\n всех включённых правил IPA.\n\n Если не указан параметр --rules, выполнить имитацию всех включённых правил IPA.\n По умолчанию в IPA имеется общее ограничение количества извлекаемых записей, его можно изменить с помощью параметра --sizelimit.\n\n ПРИМЕРЫ:\n\n 1. Использовать все включённые правила HBAC в базе данных IPA:\n $ ipa hbactest --user=a1a --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\n --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\n --rules=myrule --rules=my-second-rule --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\n --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\n --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 также применяются к пользователям, которые выполняют доступ к ресурсам IPA из доверенного домена. Пользователи и группы доверенного домена (и их SID) затем могут быть привязаны к внешним группам, которые могут быть участниками POSIX-групп в IPA. Такие привязки можно использовать в правилах HBAC, тем самым разрешая доступ к ресурсам, которые защищены системой HBAC.\n\nПодключаемый модуль hbactest позволяет проверять доступ как для локальных пользователей IPA, так и для пользователей из доверенных доменов, как с полным именем пользователя, так и по SID пользователей. В таких именах пользователей должен быть указан доверенный домен в краткой форме (DOMAIN\\Administrator) или имя учётной записи пользователя (UPN), Administrator@ad.test.\n\nОбратите внимание, что выполнять hbactest с аргументом пользователя доверенного домена в параметре --user могут только участники группы \"trust admins\".\n\nПРИМЕРЫ:\n\n 1. Проверить, соответствует ли пользователь из доверенного домена, указанный по краткому имени, какому-либо правилу:\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 $ ipa hbactest --user 'Administrator@domain.com' --host `hostname` --service sshd\n --------------------\n Доступ предоставлен: Да\n --------------------\n Соответствующие правила: allow_all\n Соответствующие правила: can_login\n\n 3. Проверить, соответствует ли пользователь из доверенного домена, указанный по 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. Проверить, соответствует ли другой пользователь из доверенного домена, указанный по SID, какому-либо правилу:\n\n $ ipa hbactest --user S-1-5-21-3035198329-144811719-1378114514-1203\n --host `hostname` --service sshd\n --------------------\n Доступ предоставлен: Да\n --------------------\n Соответствующие правила: allow_all\n Несоответствующие правила: can_login\n\n 5. Проверить, соответствует ли другой пользователь из доверенного домена, указанный по краткому имени, какому-либо правилу:\n\n $ ipa hbactest --user 'DOMAIN\\Otheruser' --host `hostname` --service sshd\n --------------------\n Доступ предоставлен: Да\n --------------------\n Соответствующие правила: allow_all\n Несоответствующие правила: can_login\n\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": 2727958, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=492a5f1bfd7f3571", "url": "https://translate.fedoraproject.org/api/units/2727958/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:01.191043Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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Имитация использования управления доступом на основе узла\n\nПравила HBAC управляют тем, кто и на каких узлах сможет получать доступ к определённым службам. Вы можете воспользоваться HBAC для определения тех пользователей и групп, которые будут иметь доступ к определённой службе или группе служб на целевом узле. \n\nТак как применение правил HBAC подразумевает использование рабочей среды, этот подключаемый модуль предназначен для обеспечения имитации оценки правил HBAC при отсутствии доступа к рабочей среде.\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 Если указан параметр --enabled, добавить все включённые правила HBAC к имитации.\n\n Если указан параметр --disabled, добавить все отключённые правила HBAC к имитации.\n\n Если указан параметр --nodetail, не возвращать данные о соответствующих или не соответствующих правилах.\n\n Если одновременно указаны параметры --rules и --enabled, выполнить имитацию --rules _и_\n всех включённых правил IPA.\n\n Если не указан параметр --rules, выполнить имитацию всех включённых правил IPA.\n По умолчанию в IPA имеется общее ограничение количества извлекаемых записей, его можно изменить с помощью параметра --sizelimit.\n\n ПРИМЕРЫ:\n\n 1. Использовать все включённые правила HBAC в базе данных IPA:\n $ ipa hbactest --user=a1a --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 \\\\\n --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 \\\\\n --rules=myrule --rules=my-second-rule --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 \\\\\n --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 \\\\\n --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 также применяются к пользователям, которые выполняют доступ к ресурсам IPA из доверенного домена. Пользователи и группы доверенного домена (и их SID) затем могут быть привязаны к внешним группам, которые могут быть участниками POSIX-групп в IPA. Такие привязки можно использовать в правилах HBAC, тем самым разрешая доступ к ресурсам, которые защищены системой HBAC.\n\nПодключаемый модуль hbactest позволяет проверять доступ как для локальных пользователей IPA, так и для пользователей из доверенных доменов, как с полным именем пользователя, так и по SID пользователей. В таких именах пользователей должен быть указан доверенный домен в краткой форме (DOMAIN\\Administrator) или имя учётной записи пользователя (UPN), Administrator@ad.test.\n\nОбратите внимание, что выполнять hbactest с аргументом пользователя доверенного домена в параметре --user могут только участники группы \"trust admins\".\n\nПРИМЕРЫ:\n\n 1. Проверить, соответствует ли пользователь из доверенного домена, указанный по краткому имени, какому-либо правилу:\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 $ ipa hbactest --user 'Administrator@domain.com' --host `hostname` --service sshd\n --------------------\n Доступ предоставлен: Да\n --------------------\n Соответствующие правила: allow_all\n Соответствующие правила: can_login\n\n 3. Проверить, соответствует ли пользователь из доверенного домена, указанный по 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. Проверить, соответствует ли другой пользователь из доверенного домена, указанный по SID, какому-либо правилу:\n\n $ ipa hbactest --user S-1-5-21-3035198329-144811719-1378114514-1203 \\\\\n --host `hostname` --service sshd\n --------------------\n Доступ предоставлен: Да\n --------------------\n Соответствующие правила: allow_all\n Несоответствующие правила: can_login\n\n 5. Проверить, соответствует ли другой пользователь из доверенного домена, указанный по краткому имени, какому-либо правилу:\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": 2727960, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=e3f81122a786cbd1", "url": "https://translate.fedoraproject.org/api/units/2727960/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:01.238742Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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Записи неподтверждённых пользователей находятся непосредственно в контейнере: \"cn=stage users,\ncn=accounts, cn=provisioning, SUFFIX\". Пользователь не может проходить аутентификацию с помощью этих записей (даже если они содержат учётные данные), они являются кандидатами на преобразование в активные записи. \n\nАктивные записи пользователей являются пользователями Posix, находящимися непосредственно в контейнере: \"cn=accounts, SUFFIX\". Пользователь может проходить аутентификацию с помощью активных записей, если они содержат учётные данные.\n\nУдалённые записи пользователей являются пользователями Posix, находящимися непосредственно в контейнере: \"cn=deleted users, cn=accounts, cn=provisioning, SUFFIX\". Пользователь не может проходить аутентификацию с помощью этих записей (даже если они содержат учётные данные).\n\nКонтейнер неподтверждённых пользователей содержит записи:\n - созданные с помощью команд \"stageuser-add\", которые являются пользователями Posix\n - созданные с помощью внешней системы подготовки \n\nКорректная запись неподтверждённого пользователя ДОЛЖНА отвечать следующим требованиям:\n - RDN записи имеет значение \"uid\"\n - ipaUniqueID имеет значение \"autogenerate\"\n\nIPA поддерживает широкий спектр форматов имён пользователей, но следует учитывать те ограничения, которые могут существовать в конкретной среде. Например, имена пользователей, которые начинаются с цифры или превышают определённую длину, могут привести к проблемам в некоторых системах UNIX.\nИспользуйте команду \"ipa config-mod\" для изменения формата имени пользователя, разрешённого средствами IPA.\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": 2727962, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=29595636cec10048", "url": "https://translate.fedoraproject.org/api/units/2727962/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:01.278221Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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Записи неподтверждённых пользователей находятся непосредственно в контейнере: \"cn=stage users,\ncn=accounts, cn=provisioning, SUFFIX\". Пользователи не могут проходить аутентификацию с помощью этих записей (даже если они содержат учётные данные). Эти записи только являются кандидатами на преобразование в активные записи. \n\nАктивные записи пользователей являются пользователями Posix, находящимися непосредственно в контейнере: \"cn=accounts, SUFFIX\". Пользователи могут проходить аутентификацию с помощью активных записей, если они содержат учётные данные.\n\nУдалённые записи пользователей являются пользователями Posix, находящимися непосредственно в контейнере: \"cn=deleted users, cn=accounts, cn=provisioning, SUFFIX\". Пользователи не могут проходить аутентификацию с помощью этих записей, даже если они содержат учётные данные.\n\nКонтейнер неподтверждённых пользователей содержит записи:\n - созданные с помощью команд \"stageuser-add\", которые являются пользователями Posix\n - созданные с помощью внешней системы подготовки \n\nКорректная запись неподтверждённого пользователя ДОЛЖНА отвечать следующим требованиям:\n - RDN записи имеет значение \"uid\"\n - ipaUniqueID имеет значение \"autogenerate\"\n\nIPA поддерживает широкий спектр форматов имён пользователей, но следует учитывать те ограничения, которые могут существовать в конкретной среде. Например, имена пользователей, которые начинаются с цифры или превышают определённую длину, могут привести к проблемам в некоторых системах UNIX.\nИспользуйте команду \"ipa config-mod\" для изменения формата имени пользователя, разрешённого средствами IPA.\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" ], "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": 2727963, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=1d00d8618e82d5ae", "url": "https://translate.fedoraproject.org/api/units/2727963/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:01.327634Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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" ], "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": 2727964, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=aa5dda5569e28296", "url": "https://translate.fedoraproject.org/api/units/2727964/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:01.342825Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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) можно добавлять для выпуска с заданной областью сертификатов 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": true, "num_words": 13, "source_unit": "https://translate.fedoraproject.org/api/units/2717840/?format=api", "priority": 100, "id": 2727965, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=4821acfa02cbbbe2", "url": "https://translate.fedoraproject.org/api/units/2727965/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:01.355834Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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\") позволяет системному администратору делегировать полномочия, чтобы дать определённым пользователям (или группам пользователей) возможность выполнять некоторые (или все) команды от имени пользователя \"root\" или другого пользователя, вместе с тем предоставляя журнал аудита команд и их аргументов.\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": 2727966, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=f394e66173565bd2", "url": "https://translate.fedoraproject.org/api/units/2727966/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:01.371669Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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": 2727967, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=62be1bef5f2ff071", "url": "https://translate.fedoraproject.org/api/units/2727967/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:01.393854Z", "last_updated": "2023-06-16T11:46:33.795393Z" }, { "translation": "https://translate.fedoraproject.org/api/translations/freeipa/ipa-4-8/ru/?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": 2727968, "web_url": "https://translate.fedoraproject.org/translate/freeipa/ipa-4-8/ru/?checksum=9932781c0e32bb57", "url": "https://translate.fedoraproject.org/api/units/2727968/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-03-25T09:51:01.411382Z", "last_updated": "2023-06-16T11:46:33.795393Z" } ] }