From 74aa0bc6779af38018a03fd2cf4419fe85917904 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Fri, 19 Apr 2024 07:31:45 +0200 Subject: Adding upstream version 2.9.4. Signed-off-by: Daniel Baumann --- src/man/pt_BR/include/ad_modified_defaults.xml | 104 +++++++++ src/man/pt_BR/include/autofs_attributes.xml | 66 ++++++ src/man/pt_BR/include/autofs_restart.xml | 5 + src/man/pt_BR/include/debug_levels.xml | 97 ++++++++ src/man/pt_BR/include/debug_levels_tools.xml | 77 +++++++ src/man/pt_BR/include/failover.xml | 120 ++++++++++ src/man/pt_BR/include/homedir_substring.xml | 17 ++ src/man/pt_BR/include/ipa_modified_defaults.xml | 123 ++++++++++ src/man/pt_BR/include/krb5_options.xml | 153 +++++++++++++ src/man/pt_BR/include/ldap_id_mapping.xml | 284 ++++++++++++++++++++++++ src/man/pt_BR/include/ldap_search_bases.xml | 31 +++ src/man/pt_BR/include/local.xml | 17 ++ src/man/pt_BR/include/override_homedir.xml | 78 +++++++ src/man/pt_BR/include/param_help.xml | 10 + src/man/pt_BR/include/param_help_py.xml | 10 + src/man/pt_BR/include/seealso.xml | 49 ++++ src/man/pt_BR/include/service_discovery.xml | 41 ++++ src/man/pt_BR/include/upstream.xml | 3 + 18 files changed, 1285 insertions(+) create mode 100644 src/man/pt_BR/include/ad_modified_defaults.xml create mode 100644 src/man/pt_BR/include/autofs_attributes.xml create mode 100644 src/man/pt_BR/include/autofs_restart.xml create mode 100644 src/man/pt_BR/include/debug_levels.xml create mode 100644 src/man/pt_BR/include/debug_levels_tools.xml create mode 100644 src/man/pt_BR/include/failover.xml create mode 100644 src/man/pt_BR/include/homedir_substring.xml create mode 100644 src/man/pt_BR/include/ipa_modified_defaults.xml create mode 100644 src/man/pt_BR/include/krb5_options.xml create mode 100644 src/man/pt_BR/include/ldap_id_mapping.xml create mode 100644 src/man/pt_BR/include/ldap_search_bases.xml create mode 100644 src/man/pt_BR/include/local.xml create mode 100644 src/man/pt_BR/include/override_homedir.xml create mode 100644 src/man/pt_BR/include/param_help.xml create mode 100644 src/man/pt_BR/include/param_help_py.xml create mode 100644 src/man/pt_BR/include/seealso.xml create mode 100644 src/man/pt_BR/include/service_discovery.xml create mode 100644 src/man/pt_BR/include/upstream.xml (limited to 'src/man/pt_BR/include') diff --git a/src/man/pt_BR/include/ad_modified_defaults.xml b/src/man/pt_BR/include/ad_modified_defaults.xml new file mode 100644 index 0000000..6ee0537 --- /dev/null +++ b/src/man/pt_BR/include/ad_modified_defaults.xml @@ -0,0 +1,104 @@ + + MODIFIED DEFAULT OPTIONS + + Certain option defaults do not match their respective backend provider +defaults, these option names and AD provider-specific defaults are listed +below: + + + KRB5 Provider + + + + krb5_validate = true + + + + + krb5_use_enterprise_principal = true + + + + + + LDAP Provider + + + + ldap_schema = ad + + + + + ldap_force_upper_case_realm = true + + + + + ldap_id_mapping = true + + + + + ldap_sasl_mech = GSS-SPNEGO + + + + + ldap_referrals = false + + + + + ldap_account_expire_policy = ad + + + + + ldap_use_tokengroups = true + + + + + ldap_sasl_authid = sAMAccountName@REALM (typically SHORTNAME$@REALM) + + + The AD provider looks for a different principal than the LDAP provider by +default, because in an Active Directory environment the principals are +divided into two groups - User Principals and Service Principals. Only User +Principal can be used to obtain a TGT and by default, computer object's +principal is constructed from its sAMAccountName and the AD realm. The +well-known host/hostname@REALM principal is a Service Principal and thus +cannot be used to get a TGT with. + + + + + + NSS configuration + + + + fallback_homedir = /home/%d/%u + + + The AD provider automatically sets "fallback_homedir = /home/%d/%u" to +provide personal home directories for users without the homeDirectory +attribute. If your AD Domain is properly populated with Posix attributes, +and you want to avoid this fallback behavior, you can explicitly set +"fallback_homedir = %o". + + + Note that the system typically expects a home directory in /home/%u +folder. If you decide to use a different directory structure, some other +parts of your system may need adjustments. + + + For example automated creation of home directories in combination with +selinux requires selinux adjustment, otherwise the home directory will be +created with wrong selinux context. + + + + + diff --git a/src/man/pt_BR/include/autofs_attributes.xml b/src/man/pt_BR/include/autofs_attributes.xml new file mode 100644 index 0000000..8016b31 --- /dev/null +++ b/src/man/pt_BR/include/autofs_attributes.xml @@ -0,0 +1,66 @@ + + + ldap_autofs_map_object_class (string) + + + The object class of an automount map entry in LDAP. + + + Default: nisMap (rfc2307, autofs_provider=ad), otherwise automountMap + + + + + + ldap_autofs_map_name (string) + + + The name of an automount map entry in LDAP. + + + Default: nisMapName (rfc2307, autofs_provider=ad), otherwise +automountMapName + + + + + + ldap_autofs_entry_object_class (string) + + + The object class of an automount entry in LDAP. The entry usually +corresponds to a mount point. + + + Default: nisObject (rfc2307, autofs_provider=ad), otherwise automount + + + + + + ldap_autofs_entry_key (string) + + + The key of an automount entry in LDAP. The entry usually corresponds to a +mount point. + + + Default: cn (rfc2307, autofs_provider=ad), otherwise automountKey + + + + + + ldap_autofs_entry_value (string) + + + The key of an automount entry in LDAP. The entry usually corresponds to a +mount point. + + + Default: nisMapEntry (rfc2307, autofs_provider=ad), otherwise +automountInformation + + + + diff --git a/src/man/pt_BR/include/autofs_restart.xml b/src/man/pt_BR/include/autofs_restart.xml new file mode 100644 index 0000000..f31efe5 --- /dev/null +++ b/src/man/pt_BR/include/autofs_restart.xml @@ -0,0 +1,5 @@ + + Please note that the automounter only reads the master map on startup, so if +any autofs-related changes are made to the sssd.conf, you typically also +need to restart the automounter daemon after restarting the SSSD. + diff --git a/src/man/pt_BR/include/debug_levels.xml b/src/man/pt_BR/include/debug_levels.xml new file mode 100644 index 0000000..1f51573 --- /dev/null +++ b/src/man/pt_BR/include/debug_levels.xml @@ -0,0 +1,97 @@ + + + SSSD supports two representations for specifying the debug level. The +simplest is to specify a decimal value from 0-9, which represents enabling +that level and all lower-level debug messages. The more comprehensive option +is to specify a hexadecimal bitmask to enable or disable specific levels +(such as if you wish to suppress a level). + + + Please note that each SSSD service logs into its own log file. Also please +note that enabling debug_level in the [sssd] +section only enables debugging just for the sssd process itself, not for the +responder or provider processes. The debug_level parameter +should be added to all sections that you wish to produce debug logs from. + + + In addition to changing the log level in the config file using the +debug_level parameter, which is persistent, but requires SSSD +restart, it is also possible to change the debug level on the fly using the + sss_debuglevel +8 tool. + + + Currently supported debug levels: + + + 0, 0x0010: Fatal +failures. Anything that would prevent SSSD from starting up or causes it to +cease running. + + + 1, 0x0020: Critical failures. An +error that doesn't kill SSSD, but one that indicates that at least one major +feature is not going to work properly. + + + 2, 0x0040: Serious failures. An +error announcing that a particular request or operation has failed. + + + 3, 0x0080: Minor failures. These +are the errors that would percolate down to cause the operation failure of +2. + + + 4, 0x0100: Configuration settings. + + + 5, 0x0200: Function data. + + + 6, 0x0400: Trace messages for +operation functions. + + + 7, 0x1000: Trace messages for +internal control functions. + + + 8, 0x2000: Contents of +function-internal variables that may be interesting. + + + 9, 0x4000: Extremely low-level +tracing information. + + + 9, 0x20000: Performance and +statistical data, please note that due to the way requests are processed +internally the logged execution time of a request might be longer than it +actually was. + + + 10, 0x10000: Even more low-level +libldb tracing information. Almost never really required. + + + To log required bitmask debug levels, simply add their numbers together as +shown in following examples: + + + Example: To log fatal failures, critical failures, +serious failures and function data use 0x0270. + + + Example: To log fatal failures, configuration settings, +function data, trace messages for internal control functions use 0x1310. + + + Note: The bitmask format of debug levels was introduced +in 1.7.0. + + + Default: 0x0070 (i.e. fatal, critical and serious +failures; corresponds to setting 2 in decimal notation) + + diff --git a/src/man/pt_BR/include/debug_levels_tools.xml b/src/man/pt_BR/include/debug_levels_tools.xml new file mode 100644 index 0000000..23f2f89 --- /dev/null +++ b/src/man/pt_BR/include/debug_levels_tools.xml @@ -0,0 +1,77 @@ + + + SSSD supports two representations for specifying the debug level. The +simplest is to specify a decimal value from 0-9, which represents enabling +that level and all lower-level debug messages. The more comprehensive option +is to specify a hexadecimal bitmask to enable or disable specific levels +(such as if you wish to suppress a level). + + + Currently supported debug levels: + + + 0, 0x0010: Fatal +failures. Anything that would prevent SSSD from starting up or causes it to +cease running. + + + 1, 0x0020: Critical failures. An +error that doesn't kill SSSD, but one that indicates that at least one major +feature is not going to work properly. + + + 2, 0x0040: Serious failures. An +error announcing that a particular request or operation has failed. + + + 3, 0x0080: Minor failures. These +are the errors that would percolate down to cause the operation failure of +2. + + + 4, 0x0100: Configuration settings. + + + 5, 0x0200: Function data. + + + 6, 0x0400: Trace messages for +operation functions. + + + 7, 0x1000: Trace messages for +internal control functions. + + + 8, 0x2000: Contents of +function-internal variables that may be interesting. + + + 9, 0x4000: Extremely low-level +tracing information. + + + 10, 0x10000: Even more low-level +libldb tracing information. Almost never really required. + + + To log required bitmask debug levels, simply add their numbers together as +shown in following examples: + + + Example: To log fatal failures, critical failures, +serious failures and function data use 0x0270. + + + Example: To log fatal failures, configuration settings, +function data, trace messages for internal control functions use 0x1310. + + + Note: The bitmask format of debug levels was introduced +in 1.7.0. + + + Default: 0x0070 (i.e. fatal, critical and serious +failures; corresponds to setting 2 in decimal notation) + + diff --git a/src/man/pt_BR/include/failover.xml b/src/man/pt_BR/include/failover.xml new file mode 100644 index 0000000..c1835eb --- /dev/null +++ b/src/man/pt_BR/include/failover.xml @@ -0,0 +1,120 @@ + + FAILOVER + + The failover feature allows back ends to automatically switch to a different +server if the current server fails. + + + Failover Syntax + + The list of servers is given as a comma-separated list; any number of spaces +is allowed around the comma. The servers are listed in order of +preference. The list can contain any number of servers. + + + For each failover-enabled config option, two variants exist: +primary and backup. The idea is +that servers in the primary list are preferred and backup servers are only +searched if no primary servers can be reached. If a backup server is +selected, a timeout of 31 seconds is set. After this timeout SSSD will +periodically try to reconnect to one of the primary servers. If it succeeds, +it will replace the current active (backup) server. + + + + The Failover Mechanism + + The failover mechanism distinguishes between a machine and a service. The +back end first tries to resolve the hostname of a given machine; if this +resolution attempt fails, the machine is considered offline. No further +attempts are made to connect to this machine for any other service. If the +resolution attempt succeeds, the back end tries to connect to a service on +this machine. If the service connection attempt fails, then only this +particular service is considered offline and the back end automatically +switches over to the next service. The machine is still considered online +and might still be tried for another service. + + + Further connection attempts are made to machines or services marked as +offline after a specified period of time; this is currently hard coded to 30 +seconds. + + + If there are no more machines to try, the back end as a whole switches to +offline mode, and then attempts to reconnect every 30 seconds. + + + + Failover time outs and tuning + + Resolving a server to connect to can be as simple as running a single DNS +query or can involve several steps, such as finding the correct site or +trying out multiple host names in case some of the configured servers are +not reachable. The more complex scenarios can take some time and SSSD needs +to balance between providing enough time to finish the resolution process +but on the other hand, not trying for too long before falling back to +offline mode. If the SSSD debug logs show that the server resolution is +timing out before a live server is contacted, you can consider changing the +time outs. + + + This section lists the available tunables. Please refer to their description +in the +sssd.conf5 +, manual page. + + + dns_resolver_server_timeout + + + + Time in milliseconds that sets how long would SSSD talk to a single DNS +server before trying next one. + + + Default: 1000 + + + + + + dns_resolver_op_timeout + + + + Time in seconds to tell how long would SSSD try to resolve single DNS query +(e.g. resolution of a hostname or an SRV record) before trying the next +hostname or discovery domain. + + + Default: 3 + + + + + + dns_resolver_timeout + + + + How long would SSSD try to resolve a failover service. This service +resolution internally might include several steps, such as resolving DNS SRV +queries or locating the site. + + + Default: 6 + + + + + + + For LDAP-based providers, the resolve operation is performed as part of an +LDAP connection operation. Therefore, also the +ldap_opt_timeout timeout should be set to a larger value than +dns_resolver_timeout which in turn should be set to a larger +value than dns_resolver_op_timeout which should be larger +than dns_resolver_server_timeout. + + + diff --git a/src/man/pt_BR/include/homedir_substring.xml b/src/man/pt_BR/include/homedir_substring.xml new file mode 100644 index 0000000..d7533de --- /dev/null +++ b/src/man/pt_BR/include/homedir_substring.xml @@ -0,0 +1,17 @@ + + homedir_substring (string) + + + The value of this option will be used in the expansion of the +override_homedir option if the template contains the +format string %H. An LDAP directory entry can directly +contain this template so that this option can be used to expand the home +directory path for each client machine (or operating system). It can be set +per-domain or globally in the [nss] section. A value specified in a domain +section will override one set in the [nss] section. + + + Default: /home + + + diff --git a/src/man/pt_BR/include/ipa_modified_defaults.xml b/src/man/pt_BR/include/ipa_modified_defaults.xml new file mode 100644 index 0000000..4ad4b45 --- /dev/null +++ b/src/man/pt_BR/include/ipa_modified_defaults.xml @@ -0,0 +1,123 @@ + + MODIFIED DEFAULT OPTIONS + + Certain option defaults do not match their respective backend provider +defaults, these option names and IPA provider-specific defaults are listed +below: + + + KRB5 Provider + + + + krb5_validate = true + + + + + krb5_use_fast = try + + + + + krb5_canonicalize = true + + + + + + LDAP Provider - General + + + + ldap_schema = ipa_v1 + + + + + ldap_force_upper_case_realm = true + + + + + ldap_sasl_mech = GSSAPI + + + + + ldap_sasl_minssf = 56 + + + + + ldap_account_expire_policy = ipa + + + + + ldap_use_tokengroups = true + + + + + + LDAP Provider - User options + + + + ldap_user_member_of = memberOf + + + + + ldap_user_uuid = ipaUniqueID + + + + + ldap_user_ssh_public_key = ipaSshPubKey + + + + + ldap_user_auth_type = ipaUserAuthType + + + + + + LDAP Provider - Group options + + + + ldap_group_object_class = ipaUserGroup + + + + + ldap_group_object_class_alt = posixGroup + + + + + ldap_group_member = member + + + + + ldap_group_uuid = ipaUniqueID + + + + + ldap_group_objectsid = ipaNTSecurityIdentifier + + + + + ldap_group_external_member = ipaExternalMember + + + + + diff --git a/src/man/pt_BR/include/krb5_options.xml b/src/man/pt_BR/include/krb5_options.xml new file mode 100644 index 0000000..e13ba89 --- /dev/null +++ b/src/man/pt_BR/include/krb5_options.xml @@ -0,0 +1,153 @@ + + + krb5_auth_timeout (integer) + + + Timeout in seconds after an online authentication request or change password +request is aborted. If possible, the authentication request is continued +offline. + + + Default: 6 + + + + + + krb5_validate (boolean) + + + Verify with the help of krb5_keytab that the TGT obtained has not been +spoofed. The keytab is checked for entries sequentially, and the first entry +with a matching realm is used for validation. If no entry matches the realm, +the last entry in the keytab is used. This process can be used to validate +environments using cross-realm trust by placing the appropriate keytab entry +as the last entry or the only entry in the keytab file. + + + Default: false (IPA and AD provider: true) + + + Please note that the ticket validation is the first step when checking the +PAC (see 'pac_check' in the +sssd.conf 5 + manual page for details). If ticket validation is disabled +the PAC checks will be skipped as well. + + + + + + krb5_renewable_lifetime (string) + + + Request a renewable ticket with a total lifetime, given as an integer +immediately followed by a time unit: + + + s for seconds + + + m for minutes + + + h for hours + + + d for days. + + + If there is no unit given, s is assumed. + + + NOTE: It is not possible to mix units. To set the renewable lifetime to one +and a half hours, use '90m' instead of '1h30m'. + + + Default: not set, i.e. the TGT is not renewable + + + + + + krb5_lifetime (string) + + + Request ticket with a lifetime, given as an integer immediately followed by +a time unit: + + + s for seconds + + + m for minutes + + + h for hours + + + d for days. + + + If there is no unit given s is assumed. + + + NOTE: It is not possible to mix units. To set the lifetime to one and a +half hours please use '90m' instead of '1h30m'. + + + Default: not set, i.e. the default ticket lifetime configured on the KDC. + + + + + + krb5_renew_interval (string) + + + The time in seconds between two checks if the TGT should be renewed. TGTs +are renewed if about half of their lifetime is exceeded, given as an integer +immediately followed by a time unit: + + + s for seconds + + + m for minutes + + + h for hours + + + d for days. + + + If there is no unit given, s is assumed. + + + NOTE: It is not possible to mix units. To set the renewable lifetime to one +and a half hours, use '90m' instead of '1h30m'. + + + If this option is not set or is 0 the automatic renewal is disabled. + + + Default: not set + + + + + + krb5_canonicalize (boolean) + + + Specifies if the host and user principal should be canonicalized. This +feature is available with MIT Kerberos 1.7 and later versions. + + + + Default: false + + + + diff --git a/src/man/pt_BR/include/ldap_id_mapping.xml b/src/man/pt_BR/include/ldap_id_mapping.xml new file mode 100644 index 0000000..f80be8d --- /dev/null +++ b/src/man/pt_BR/include/ldap_id_mapping.xml @@ -0,0 +1,284 @@ + + ID MAPPING + + The ID-mapping feature allows SSSD to act as a client of Active Directory +without requiring administrators to extend user attributes to support POSIX +attributes for user and group identifiers. + + + NOTE: When ID-mapping is enabled, the uidNumber and gidNumber attributes are +ignored. This is to avoid the possibility of conflicts between +automatically-assigned and manually-assigned values. If you need to use +manually-assigned values, ALL values must be manually-assigned. + + + Please note that changing the ID mapping related configuration options will +cause user and group IDs to change. At the moment, SSSD does not support +changing IDs, so the SSSD database must be removed. Because cached passwords +are also stored in the database, removing the database should only be +performed while the authentication servers are reachable, otherwise users +might get locked out. In order to cache the password, an authentication must +be performed. It is not sufficient to use +sss_cache 8 + to remove the database, rather the process consists of: + + + + Making sure the remote servers are reachable + + + + + Stopping the SSSD service + + + + + Removing the database + + + + + Starting the SSSD service + + + + Moreover, as the change of IDs might necessitate the adjustment of other +system properties such as file and directory ownership, it's advisable to +plan ahead and test the ID mapping configuration thoroughly. + + + + Mapping Algorithm + + Active Directory provides an objectSID for every user and group object in +the directory. This objectSID can be broken up into components that +represent the Active Directory domain identity and the relative identifier +(RID) of the user or group object. + + + The SSSD ID-mapping algorithm takes a range of available UIDs and divides it +into equally-sized component sections - called "slices"-. Each slice +represents the space available to an Active Directory domain. + + + When a user or group entry for a particular domain is encountered for the +first time, the SSSD allocates one of the available slices for that +domain. In order to make this slice-assignment repeatable on different +client machines, we select the slice based on the following algorithm: + + + The SID string is passed through the murmurhash3 algorithm to convert it to +a 32-bit hashed value. We then take the modulus of this value with the total +number of available slices to pick the slice. + + + NOTE: It is possible to encounter collisions in the hash and subsequent +modulus. In these situations, we will select the next available slice, but +it may not be possible to reproduce the same exact set of slices on other +machines (since the order that they are encountered will determine their +slice). In this situation, it is recommended to either switch to using +explicit POSIX attributes in Active Directory (disabling ID-mapping) or +configure a default domain to guarantee that at least one is always +consistent. See Configuration for details. + + + + + Configuration + + Minimum configuration (in the [domain/DOMAINNAME] section): + + + +ldap_id_mapping = True +ldap_schema = ad + + + + The default configuration results in configuring 10,000 slices, each capable +of holding up to 200,000 IDs, starting from 200,000 and going up to +2,000,200,000. This should be sufficient for most deployments. + + + Advanced Configuration + + + ldap_idmap_range_min (integer) + + + Specifies the lower (inclusive) bound of the range of POSIX IDs to use for +mapping Active Directory user and group SIDs. It is the first POSIX ID which +can be used for the mapping. + + + NOTE: This option is different from min_id in that +min_id acts to filter the output of requests to this domain, +whereas this option controls the range of ID assignment. This is a subtle +distinction, but the good general advice would be to have +min_id be less-than or equal to +ldap_idmap_range_min + + + Default: 200000 + + + + + ldap_idmap_range_max (integer) + + + Specifies the upper (exclusive) bound of the range of POSIX IDs to use for +mapping Active Directory user and group SIDs. It is the first POSIX ID which +cannot be used for the mapping anymore, i.e. one larger than the last one +which can be used for the mapping. + + + NOTE: This option is different from max_id in that +max_id acts to filter the output of requests to this domain, +whereas this option controls the range of ID assignment. This is a subtle +distinction, but the good general advice would be to have +max_id be greater-than or equal to +ldap_idmap_range_max + + + Default: 2000200000 + + + + + ldap_idmap_range_size (integer) + + + Specifies the number of IDs available for each slice. If the range size +does not divide evenly into the min and max values, it will create as many +complete slices as it can. + + + NOTE: The value of this option must be at least as large as the highest user +RID planned for use on the Active Directory server. User lookups and login +will fail for any user whose RID is greater than this value. + + + For example, if your most recently-added Active Directory user has +objectSid=S-1-5-21-2153326666-2176343378-3404031434-1107, +ldap_idmap_range_size must be at least 1108 as range size is +equal to maximal SID minus minimal SID plus one (e.g. 1108 = 1107 - 0 + 1). + + + It is important to plan ahead for future expansion, as changing this value +will result in changing all of the ID mappings on the system, leading to +users with different local IDs than they previously had. + + + Default: 200000 + + + + + ldap_idmap_default_domain_sid (string) + + + Specify the domain SID of the default domain. This will guarantee that this +domain will always be assigned to slice zero in the ID map, bypassing the +murmurhash algorithm described above. + + + Default: not set + + + + + ldap_idmap_default_domain (string) + + + Specify the name of the default domain. + + + Default: not set + + + + + ldap_idmap_autorid_compat (boolean) + + + Changes the behavior of the ID-mapping algorithm to behave more similarly to +winbind's idmap_autorid algorithm. + + + When this option is configured, domains will be allocated starting with +slice zero and increasing monotonically with each additional domain. + + + NOTE: This algorithm is non-deterministic (it depends on the order that +users and groups are requested). If this mode is required for compatibility +with machines running winbind, it is recommended to also use the +ldap_idmap_default_domain_sid option to guarantee that at +least one domain is consistently allocated to slice zero. + + + Default: False + + + + + ldap_idmap_helper_table_size (integer) + + + Maximal number of secondary slices that is tried when performing mapping +from UNIX id to SID. + + + Note: Additional secondary slices might be generated when SID is being +mapped to UNIX id and RID part of SID is out of range for secondary slices +generated so far. If value of ldap_idmap_helper_table_size is equal to 0 +then no additional secondary slices are generated. + + + Default: 10 + + + + + + + + + Well-Known SIDs + + SSSD supports to look up the names of Well-Known SIDs, i.e. SIDs with a +special hardcoded meaning. Since the generic users and groups related to +those Well-Known SIDs have no equivalent in a Linux/UNIX environment no +POSIX IDs are available for those objects. + + + The SID name space is organized in authorities which can be seen as +different domains. The authorities for the Well-Known SIDs are + + Null Authority + World Authority + Local Authority + Creator Authority + Mandatory Label Authority + Authentication Authority + NT Authority + Built-in + + The capitalized version of these names are used as domain names when +returning the fully qualified name of a Well-Known SID. + + + Since some utilities allow to modify SID based access control information +with the help of a name instead of using the SID directly SSSD supports to +look up the SID by the name as well. To avoid collisions only the fully +qualified names can be used to look up Well-Known SIDs. As a result the +domain names NULL AUTHORITY, WORLD AUTHORITY, +LOCAL AUTHORITY, CREATOR AUTHORITY, +MANDATORY LABEL AUTHORITY, AUTHENTICATION +AUTHORITY, NT AUTHORITY and BUILTIN +should not be used as domain names in sssd.conf. + + + + diff --git a/src/man/pt_BR/include/ldap_search_bases.xml b/src/man/pt_BR/include/ldap_search_bases.xml new file mode 100644 index 0000000..189f862 --- /dev/null +++ b/src/man/pt_BR/include/ldap_search_bases.xml @@ -0,0 +1,31 @@ + + + An optional base DN, search scope and LDAP filter to restrict LDAP searches +for this attribute type. + + + syntax: +search_base[?scope?[filter][?search_base?scope?[filter]]*] + + + + The scope can be one of "base", "onelevel" or "subtree". The scope functions +as specified in section 4.5.1.2 of http://tools.ietf.org/html/rfc4511 + + + The filter must be a valid LDAP search filter as specified by +http://www.ietf.org/rfc/rfc2254.txt + + + For examples of this syntax, please refer to the +ldap_search_base examples section. + + + Default: the value of ldap_search_base + + + Please note that specifying scope or filter is not supported for searches +against an Active Directory Server that might yield a large number of +results and trigger the Range Retrieval extension in the response. + + diff --git a/src/man/pt_BR/include/local.xml b/src/man/pt_BR/include/local.xml new file mode 100644 index 0000000..ce849a3 --- /dev/null +++ b/src/man/pt_BR/include/local.xml @@ -0,0 +1,17 @@ + + THE LOCAL DOMAIN + + In order to function correctly, a domain with +id_provider=local must be created and the SSSD must be +running. + + + The administrator might want to use the SSSD local users instead of +traditional UNIX users in cases where the group nesting (see +sss_groupadd 8 +) is needed. The local users are also useful for testing and +development of the SSSD without having to deploy a full remote server. The +sss_user* and sss_group* tools use a +local LDB storage to store users and groups. + + diff --git a/src/man/pt_BR/include/override_homedir.xml b/src/man/pt_BR/include/override_homedir.xml new file mode 100644 index 0000000..68a1c5e --- /dev/null +++ b/src/man/pt_BR/include/override_homedir.xml @@ -0,0 +1,78 @@ + +override_homedir (string) + + + Override the user's home directory. You can either provide an absolute value +or a template. In the template, the following sequences are substituted: + + + %u + login name + + + %U + UID number + + + %d + domain name + + + %f + fully qualified user name (user@domain) + + + %l + The first letter of the login name. + + + %P + UPN - User Principal Name (name@REALM) + + + %o + + The original home directory retrieved from the identity provider. + + + + %h + + The original home directory retrieved from the identity provider, but in +lower case. + + + + %H + + The value of configure option homedir_substring. + + + + %% + a literal '%' + + + + + + This option can also be set per-domain. + + + example: +override_homedir = /home/%u + + + + Default: Not set (SSSD will use the value retrieved from LDAP) + + + Please note, the home directory from a specific override for the user, +either locally (see +sss_override +8) or centrally managed IPA +id-overrides, has a higher precedence and will be used instead of the value +given by override_homedir. + + + diff --git a/src/man/pt_BR/include/param_help.xml b/src/man/pt_BR/include/param_help.xml new file mode 100644 index 0000000..d28020b --- /dev/null +++ b/src/man/pt_BR/include/param_help.xml @@ -0,0 +1,10 @@ + + + , + + + + Display help message and exit. + + + diff --git a/src/man/pt_BR/include/param_help_py.xml b/src/man/pt_BR/include/param_help_py.xml new file mode 100644 index 0000000..a2478bf --- /dev/null +++ b/src/man/pt_BR/include/param_help_py.xml @@ -0,0 +1,10 @@ + + + , + + + + Display help message and exit. + + + diff --git a/src/man/pt_BR/include/seealso.xml b/src/man/pt_BR/include/seealso.xml new file mode 100644 index 0000000..1a8ed32 --- /dev/null +++ b/src/man/pt_BR/include/seealso.xml @@ -0,0 +1,49 @@ + + SEE ALSO + + sssd8 +, +sssd.conf5 +, +sssd-ldap5 +, +sssd-ldap-attributes5 +, +sssd-krb55 +, +sssd-simple5 +, +sssd-ipa5 +, +sssd-ad5 +, +sssd-files5 +, +sssd-sudo 5 +, +sssd-session-recording +5 , +sss_cache8 +, +sss_debuglevel8 +, +sss_obfuscate8 +, +sss_seed8 +, +sssd_krb5_locator_plugin8 +, +sss_ssh_authorizedkeys +8 , +sss_ssh_knownhostsproxy +8 , sssd-ifp +5 , +pam_sss8 +. +sss_rpcidmapd 5 + +sssd-systemtap 5 + + + diff --git a/src/man/pt_BR/include/service_discovery.xml b/src/man/pt_BR/include/service_discovery.xml new file mode 100644 index 0000000..2e417a9 --- /dev/null +++ b/src/man/pt_BR/include/service_discovery.xml @@ -0,0 +1,41 @@ + + SERVICE DISCOVERY + + The service discovery feature allows back ends to automatically find the +appropriate servers to connect to using a special DNS query. This feature is +not supported for backup servers. + + + Configuration + + If no servers are specified, the back end automatically uses service +discovery to try to find a server. Optionally, the user may choose to use +both fixed server addresses and service discovery by inserting a special +keyword, _srv_, in the list of servers. The order of +preference is maintained. This feature is useful if, for example, the user +prefers to use service discovery whenever possible, and fall back to a +specific server when no servers can be discovered using DNS. + + + + The domain name + + Please refer to the dns_discovery_domain parameter in the + sssd.conf +5 manual page for more details. + + + + The protocol + + The queries usually specify _tcp as the protocol. Exceptions are documented +in respective option description. + + + + See Also + + For more information on the service discovery mechanism, refer to RFC 2782. + + + diff --git a/src/man/pt_BR/include/upstream.xml b/src/man/pt_BR/include/upstream.xml new file mode 100644 index 0000000..2a4ad16 --- /dev/null +++ b/src/man/pt_BR/include/upstream.xml @@ -0,0 +1,3 @@ + +SSSD The SSSD upstream - +https://github.com/SSSD/sssd/ -- cgit v1.2.3