On 08/04/2011 04:12 PM, Rich Megginson wrote: > On 08/04/2011 02:05 PM, Ian Stokes-Rees wrote: >> >> >> On 8/3/11 6:13 PM, Dmitri Pal wrote: >>> On 08/03/2011 10:10 AM, Ian Stokes-Rees wrote: >>>> If there were some way to securely embed an arbitrary string in the >>>> user profile, that would go a long way to solving this problem. At >>>> least 4KB to cover a 2048 X.509 public key, but ideally 10 KB or >>>> more. To remove the ACL complexity, just having it accessible only by >>>> the user (token or password based fetch) would be suitable. >>> Do not quite understand how that would work or what you mean. >> >> I've just realized that I think the functionality I'm looking for is >> already available. I want the same system that is used for storing >> passwords. Consider the following trace: >> >> $ ldapsearch -h freeipa -b >> uid=tester,cn=users,cn=portal,dc=nebiogrid,dc=org -Y GSSAPI -LLL -d 0 >> -T ~/.ldapresults/ >> >> SASL/GSSAPI authentication started >> SASL username: [email protected] >> SASL SSF: 56 >> SASL data security layer installed. >> dn: uid=tester,cn=users,cn=portal,dc=nebiogrid,dc=org >> objectClass: person >> objectClass: posixAccount >> objectClass: account >> objectClass: inetOrgPerson >> objectClass: top >> objectClass: organizationalPerson >> givenName: test >> sn: test >> cn: test test >> mail: [email protected] >> uidNumber: 1031 >> gidNumber: 1031 >> homeDirectory: /p/home//tester >> uid: tester >> userPassword:: e2NyeXB0fXNCb2drN3p4c2lha1E= >> >> [aside: I'd love a tip on how to get rid of the non-LDIF SASL headers] >> >> The userpassword (hash) is stored in base-64 format and is only >> accessible by me because I have permissions to access this. Some >> other user doing the same query would not get the userPassword >> attribute. Even better, I can use the "-tt" option to write the >> base64-decoded content to a file. >> >> The parts of the puzzle that I'd have to work out are: >> >> 1. are there objectClass schemas that have fields that would be >> suitable for a set of common private keys (rsa1, rsa2, dsa, gpg, pgp, >> and x509)? > x509 schema are included with 389 (05rfc4523.ldif et. al.) > I think there is a schema for storage of ssh keys
Take a look at this: https://fedorahosted.org/freeipa/ticket/754 http://code.google.com/p/openssh-lpk/ Patches are welcome ;-) >> >> 2. if not, instructions on how to set up such a schema (basically >> with exactly the set of attributes above), with the fields being >> base64 (binary?) > Take a look at the existing schema. For most fields that hold opaque > blob data, you will probably want to use OctetString syntax. >> >> 3. what do I have to do to get the behavior that only certain parties >> can read a particular attribute? > Read up on Access Control (acis): > http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Managing_Access_Control >> >> 4. any way to get ldapsearch to write out particular attributes to >> particular files? > Not really - all you have is -T and -tt > But any non-trivial application is not going to use ldapsearch as the > main interface for getting these values. I suggest using python with > python-ldap. >> >> Thanks, >> >> Ian >> >> >> _______________________________________________ >> Freeipa-users mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > _______________________________________________ > Freeipa-users mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/
_______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
