MJD Shopping Account wrote:
Either way is ok. But you still have to restart the server after adding the entry.I'm reading with interest the many recent articles on the PAM passthru plugin. I'm hoping to implement it here and have a few questions. Do you have to add the dn: entry (example in the plugin README) by way of editing the dse.ldif, or can it also be added via an 'ldapadd -f <file>.ldif' command?
How does use of this plugin relate to setting the userPassword attribute to something like '{KERBEROS}user@REALM'? Is that a completely separate method for using kerberos?
The default suggested setup is with pamIDMapMethod = RDN, so this should map to 'uid' for my users. I assume with pamFallback = FALSE that the userPassword attribute never gets used?
Correct.
I'm hoping to test the basic setup, but will eventually need to support users in different KerberosV realms. I am imagining in that case that I should use pamIDMapMethod = ENTRY with pamIDAttr set appropriately and filled with the full userprinciple name, ie user@REALM not just user. Yes?
Yes.
The numbering indicates the order in which it is loaded - 00 is first, 99 is last. Most of the schema shipped with the server is in the range 00-50. I suggest you use 60krb5.ldif or something like that.Last time I used PADL's MigrateTools scripts to parse flat passwd files into ldif files for user entries, it had the ability to add an attribute to a person's entry with these attributes: objectClass: kerberosSecurityObject krbName: user@realm This seems like a good candidate for the pamIDAttr value; I didn't use it at the time because I would need to find the right schema file to support this attribute. Any ideas where to find this? Once found, I assume it goes in serverroot/slapd-instance/config/schema, what would I call the file however? I don't know what the numbering on the filenames indicates.
SASL mapping should work for SASL BINDs. The PAM passthru plugin should only be used in those cases where you have a client that only supports simple (i.e. username/password) BIND.My setup: I'm testing on a FDS 1.0.4 install runing on RedHat 4; I am part of a network that uses Active Directory for Window authentication, and I can use pam_krb5.so in my PAM setup as long as I'm using only one realm. I think this passthrough module is a good match for what I need, if it gets me the cross-realm capability by way of the pamIDAttr. I do NOT think I can use straight SASL mapping to do this, because I do not have sufficient privileges to add the ldap server to the AD domain, so I can't get the ldap/<server>@rREALM principle into place in AD.
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
