openstack-manuals/doc/common/tables/keystone-mapping.xml

35 lines
2.1 KiB
XML

<?xml version='1.0' encoding='UTF-8'?>
<para xmlns="http://docbook.org/ns/docbook" version="5.0">
<!-- Warning: Do not edit this file. It is automatically
generated and your changes will be overwritten.
The tool to do so lives in openstack-doc-tools repository. -->
<table rules="all" xml:id="config_table_keystone_mapping">
<caption>Description of mapping configuration options</caption>
<col width="50%"/>
<col width="50%"/>
<thead>
<tr>
<th>Configuration option = Default value</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<th colspan="2">[identity_mapping]</th>
</tr>
<tr>
<td>backward_compatible_ids = True</td>
<td>(BoolOpt) The format of user and group IDs changed in Juno for backends that do not generate UUIDs (e.g. LDAP), with keystone providing a hash mapping to the underlying attribute in LDAP. By default this mapping is disabled, which ensures that existing IDs will not change. Even when the mapping is enabled by using domain specific drivers, any users and groups from the default domain being handled by LDAP will still not be mapped to ensure their IDs remain backward compatible. Setting this value to False will enable the mapping for even the default LDAP driver. It is only safe to do this if you do not already have assignments for users and groups from the default LDAP domain, and it is acceptable for Keystone to provide the different IDs to clients than it did previously. Typically this means that the only time you can set this value to False is when configuring a fresh installation.</td>
</tr>
<tr>
<td>driver = keystone.identity.mapping_backends.sql.Mapping</td>
<td>(StrOpt) Keystone Identity Mapping backend driver.</td>
</tr>
<tr>
<td>generator = keystone.identity.id_generators.sha256.Generator</td>
<td>(StrOpt) Public ID generator for user and group entities. The Keystone identity mapper only supports generators that produce no more than 64 characters.</td>
</tr>
</tbody>
</table>
</para>