3:41 a.m.
On Thu, Apr 14, 2011 at 04:39:17PM -0400, Dmitri Pal wrote:
On 04/14/2011 03:51 PM, Linus Nordberg wrote:
> Fredrik Thulin <fredrik(a)yubico.com> wrote
> Thu, 14 Apr 2011 21:25:24 +0200:
>
> | On Thu, Apr 14, 2011 at 9:00 PM, Sumit Bose <sbose(a)redhat.com> wrote:
> | ...
> | > Yes, you can also find it in the MIT source in
> | > src/plugins/kdb/ldap/libkdb_ldap/kerberos.schema. The krbExtraData
> | > attributre is used to store the Yubikey token id for the principal. It
> | > is encoded so not easy to edit. I will add a utility to the rpm and web
> | > site to make this easy.
> |
> | I ran into the same dilemma when implementing a MultiFactor
> | authentication handler for Shibboleth. Ended up mapping usernames <->
> | YubiKey public id's in a plain text file as a proof of concept only.
>
> That's what I'll end up doing if this shows to be a too inconvenient way
> of configuring various principal attributes. For testing stuff.
>
> But let me first understand how krbExtraData ends up in
> krb5_db_entry->tl_data. From populate_krb5_db_entry()
> [plugins/kdb/ldap/libkdb_ldap/ldap_misc.c] it looks like it's a sequence
> of BER encoded TLV's. If so, I should probably just find out how to
> craft these in a reasonably convenient way.
> _______________________________________________
> authhub-devel mailing list
> authhub-devel(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/authhub-devel
I suggest we split the actual data representation in LDAP schema or
whatever back end is used from the data model and information needed by
the plugin(s) to do the work. The ID is just one piece of the puzzle.
IMO in a generic case there should be an attribute of the account that
would dictate what kind of the external authentication is required for
such account and then depending on the type of the external
authentication a blob of data that defines method specific properties
like a Yubikey ID in Yubikey case. It can have other information two.
This info will me method specific and processed by the vendor plugin.
yes, I think the issue is two-fold here. First we want a simple
representation of the data relevant for the special OTP method/device.
Here I think it would be the most easiest way that vendors will
provide their own objectclasses for their products because with a
common objectclasses it might get difficult if a user have multiple
different OTP devices.
Second the Kerberos preauthentication plugin needs to have access to the
data. I'm not sure if it might be possible to find a solution which will
work with all available kdb backends, so I will concentrate on LDAP
here. In general it would be possible to open a new connection the to
LDAP server and read the needed attributes directly in the plugin. But
since the KDC has already read data about the principal from the LDAP
server I would not prefer this solution. Currently I have only found the
tagged data stored in the krbExtraData which is suitable for arbitrary
data, with the benefit that it will work with all kdb backends. But in
general it would be nice if the kdb LDAP backend can be extended in a
way that it will read all user attributes and present them to the
pre-authentication plugin with the other Kerberos related data read from
the LDAP server.
Now to the problem at hand, how to add the Yubikey-ID. I use the
following script with a FreeIPA server:
#!/bin/bash
BASEDN="dc=otp,dc=demo"
if [ $# -ne 2 ]; then
echo "Missing arguments"
echo "usage: "$(basename $0)" pincipal Yubikey-ID"
exit 1
fi
DN=$(ldapsearch -LLL -Q -b $BASEDN -Y GSSAPI "krbPrincipalName=$1" dn |
grep '^dn: ' | head -1 |sed -e 's/^dn: //')
b=$(echo -ne "\x08\x00$(echo $2 | cut -b -12)\x00" | base64)
cat << LDIF_EOF | ldapmodify -x -D 'cn=Directory Manager' -w 12345678
dn: $DN
changetype: modify
replace: krbTicketFlags
krbTicketFlags: 256
-
add: krbExtraData
krbExtraData:: $b
LDIF_EOF
It sets the hardware preauthentication flag (krbTicketFlags: 256) and
encodes the Yubikey Id. If you want to do this manually you have to add
0x0800 before the ID, terminate it with 0x00 and encode the
result with base64. 0x0800 is the tag I have chosen for the Yubikey-ID
in src/include/kdb.h.
HTH
bye,
Sumit
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
_______________________________________________
authhub-devel mailing list
authhub-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/authhub-devel