[Fedora-directory-users] pass-thru questions

[MJD Shopping Account]

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 at 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?

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 at REALM not just user.  Yes?

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 at 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.

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.