That all principals must reside in a single sub-tree is currently () a limitation of the SASL implementation. This is BOTH where the LDAP service principal must reside, as well as where user principals must reside.
The search base DN is where a subtree-scoped DIT search will be performed. Note that if your realm does not appear here, you will see an error similar to "Nonexistent realm: ." If the realm is not enabled, the connection will be rejected. When Confidentiality is enabled, you do not need SSL/TLS to protect connections. Confidentiality means "with encryption." Confidentiality is sometimes called privacy. Use SASL with confidentiality protection. Integrity basically means "with a checksum." For GSSAPI integrity is always enabled. Use SASL for authentication only (no integrity or confidentiality protection). These SASL QoP levels are global they affect all connections using DIGEST-MD5 or GSSAPI. Listing only 'auth-conf' will allow only 'auth-conf' connections. Listing all possible levels means any level will be accepted. The QoP level directly maps to the JNDI levels.
(OPTIONAL) Enforce quality-of-protection (QoP). In our case, the KDC is ApacheDS, itself. The LDAP client will then use this as the service principal name when requesting a service ticket from a KDC. The SASL principal MUST follow the name-form The 'ldap' name component and the will be automatically added to the FQDN by the LDAP client. Set the service principal name that the server-side of the LDAP protocol provider will use to "accept" a GSSAPI context initiated by the LDAP client. You will likely find a sniffer (like WireShark) very handy for figuring out what hostnames are being assumed and whether DNS is working properly. If you are running the client and the server on the same machine, you may need to set the FQDN to be your hostname. The FQDN should be the top-most entry in your hosts file or matching A and PTR records in DNS. Elements of the SASL GSSAPI mechanism are extremely picky about the FQDN you use. The FQDN must resolve, by hosts file, or DNS. Note that the SASL support in ApacheDS is unrelated to the SASL library implementation being installed here. #Apache directory studio kerberos sasl principal install#
If Cyrus SASL GSSAPI is not present, install it with an RPM maintenance tool such as 'yum'. By default, some Linux variants do not have SASL GSSAPI support installed.
(OPTIONAL) Install GSSAPI support for LDAP tools on Linux. $ ldapsearch -H ldap://:10389 -s base -LLL supportedSASLMechanisms -x You must see 'GSSAPI' in this returned list. Regardless of the enabled authentication mechanisms, you will always be able to query the RootDSE. Note the use of the fully-qualified domain name (FQDN), ''. You can double-check your version of ApacheDS by interrogating the RootDSE for the supported SASL mechanisms. Make sure you are using ApacheDS 1.5.1, which is currently () only available from the HEAD of trunk in svn. When using SASL message privacy, connections do not need SSL to protect communications. Additionally, the GSSAPI mechanism can provide message integrity (checksums) and, optionally, message privacy (encryption). 
SASL GSSAPI allows Kerberos authentication to be used during LDAP Binds. SASL GSSAPI Authentication to ApacheDS IntroductionĪpache Directory currently supports the SASL GSSAPI mechanism. This site is in the process of being reviewed and updated.
0 kommentar(er)
