> >Or, just use >nsSaslMapBaseDNTemplate: ou=People,dc=myexample,dc=com >nsSaslMapFilterTemplate: (uid=\1) Hi Richard, I found the root cause of my problems, and they are as follows (in case anyone else happens to be searching these archives). I was using a keytab file that was readable only by root, while I was running the server as the default install user of nobody. As soon as I opened read access to that user, all kerberos / gssapi / sasl mechanisms worked. Also, the confusion I had earlier of if I should enter in the detail via the console was due to the fact I hadn't refreshed all after making the addition to the config - sasl -mapping - mymap entry with the nssaslmapping. After I refreshed, this mapping appeared under the SASL Mapping in the configuration tab. I realize this probably isn't the most secure way of doing this, so I'll probably change the default user that the server runs as. I have a few more questions regarding GSSAPI with FDS. 1) Because I have GSSAPI / SASL enabled, does this automatically enable encryption via GSSAPI? It mentioned that it will do this in the documentation, but I was unable to find the details of this. 2) I've setup a second FDS to be act as a consumer (single master replication). I've followed the administator's documentation and set a simple cn=replication manager, cn=config on both servers to act as the bind for replication (via replication agreement). I've tested this and everything is working great (directory entries, GSSAPI, etc). I would imagine that when the replication binds, the password is sent in clear text. Is this true? If I create a new user in the cn=config and create a new sasl mapping (uid=\1,cn=config) can I simply create a kerberos principal with the same name and use GSSAPI for the bind? The same question as #1 above is will this session be encrypted via GSSAPI as well? Any help would be greatly appreciated. Thanks! Jonathan
