11:38 a.m.
Hi,
Where can I find the LDAP schema used for the Yubikey plugin?
(My LDAP fu is quite limited and I'm getting tired of fiddling with
Berkeley db's).
11:44 a.m.
On 04/14/2011 12:38 PM, Linus Nordberg wrote:
Hi,
Where can I find the LDAP schema used for the Yubikey plugin?
(My LDAP fu is quite limited and I'm getting tired of fiddling with
Berkeley db's).
_______________________________________________
authhub-devel mailing list
authhub-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/authhub-devel
Sumit, please correct me if
I am wrong but there is no specific schema
that it uses yet.
This is something that we eventually need to define as we define
policies that control different auth methods.
The standard LDAP schema used by Kerberos is this:
http://k5wiki.kerberos.org/wiki/Kerberos.schema
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
2 p.m.
On Thu, Apr 14, 2011 at 12:44:06PM -0400, Dmitri Pal wrote:
On 04/14/2011 12:38 PM, Linus Nordberg wrote:
> Hi,
>
> Where can I find the LDAP schema used for the Yubikey plugin?
>
> (My LDAP fu is quite limited and I'm getting tired of fiddling with
> Berkeley db's).
> _______________________________________________
> authhub-devel mailing list
> authhub-devel(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/authhub-devel
Sumit, please correct me if I am wrong but there is no specific schema
that it uses yet.
This is something that we eventually need to define as we define
policies that control different auth methods.
The standard LDAP schema used by Kerberos is this:
http://k5wiki.kerberos.org/wiki/Kerberos.schema
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.
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
2:25 p.m.
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.
Would it make sense for this group to start specifying a schema for
storing information about arbitrary authentication tokens in LDAP?
I'm no LDAP expert either, but I know that we have at least Tier-2
connections to someone who is (and works with Linus) =).
/Fredrik
2:51 p.m.
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.
3:39 p.m.
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.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
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
4:22 a.m.
Sumit Bose <sbose(a)redhat.com> wrote
Fri, 15 Apr 2011 10:41:24 +0200:
| > 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.
And KDC plugin(s) know the names of the attributes to look for? Sounds
good from a deployment pov too. We'd have to be OK with supporting only
LDAP as a kdb backend though i suppose.
| 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.
Agreed.
| 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.
For not having to loop over the tl_data list? What do you think would
be a good way of presenting it to the plugin?
| 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.
This is exactly how I'm doing it, except I'm doing it by hand for now.
Thanks for the nice script!
5:35 a.m.
On Fri, Apr 15, 2011 at 11:22:36AM +0200, Linus Nordberg wrote:
Sumit Bose <sbose(a)redhat.com> wrote
Fri, 15 Apr 2011 10:41:24 +0200:
| > 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.
And KDC plugin(s) know the names of the attributes to look for? Sounds
Since the handling of OTP tokens from different vendors will be
different I think it is ok to have vendor/device specific names here,
too. The mid-term idea is, that the pre-authentication plugin will do
all the comminication as defined in the IETF OTP preauth draft and that
the plugin is able to load vendor specific code to process the data.
good from a deployment pov too. We'd have to be OK with
supporting only
LDAP as a kdb backend though i suppose.
| 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.
Agreed.
| 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.
For not having to loop over the tl_data list? What do you think would
be a good way of presenting it to the plugin?
The easiest way would be a generic struct in struct _krb5_db_entry_new
which has an enum which indicates the backend type and a pointer which
points to the additional backend specific data. I don't know if MIT will
like this idea.
| 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.
This is exactly how I'm doing it, except I'm doing it by hand for now.
Thanks for the nice script!
_______________________________________________
authhub-devel mailing list
authhub-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/authhub-devel
10:59 a.m.
On 04/15/2011 06:35 AM, Sumit Bose wrote:
On Fri, Apr 15, 2011 at 11:22:36AM +0200, Linus Nordberg wrote:
> Sumit Bose <sbose(a)redhat.com> wrote
> Fri, 15 Apr 2011 10:41:24 +0200:
>
> | > 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.
>
> And KDC plugin(s) know the names of the attributes to look for? Sounds
Since the handling of OTP tokens from different vendors will be
different I think it is ok to have vendor/device specific names here,
too. The mid-term idea is, that the pre-authentication plugin will do
all the comminication as defined in the IETF OTP preauth draft and that
the plugin is able to load vendor specific code to process the data.
One of the questions we need to answer is: "Is vendor specific data
searchable and sortable"? and another "how different it is from vendor
to vendor and from account to account"
I think it should not be searchable and sortable and it is vendor specific.
Also in a general case there will be accounts that are handled by one
authentication method and accounts by another authentication method in
the same deployment.
So storing the vendor specific information in a single field/attribute
as a blob of data would probably be best and leveraging the extended
data or something similar will be a way to go. However the
authentication type or vendor type should probably be more generic.
This actually reminds me a lot of a vendor specific attribute in RADIUS.
May be we should explore it and do something like it.
And I wonder whether there should be a separate "authtype"
attribute/field that would indicate to the framework what kind of vendor
plugin should be used.
The more it think about it the more I would vote on adding two more
attributes to the KDB interface that the KDB layer would return to the
framework:
a) authtype - a string that would define the algorithm that the
framework should use:
examples:
- sent the whole value of the user provided credential to an
external auth plugin X
- split the passed in credential string and send last A symbols to
external auth plugin X while first part is a kerberos password
- split the passed in credential string between method X and method Y.
Something along those lines.
b) authmethoddata - a list of the vendor specific data blobs that will
be passed to the specific vendor plugins and handled by them.
The framework would just be able to identity which blob belongs to
each plugin and pass the right blob to right plugin.
In case of yubikey it is probably something simple like the mapping
ID, but there will be probably some other data in future so the blob
should probably consist of:
vendor id, version of the blob and then the rest of data
Here is the Vendor specific attribute spec for reference - it is in the
main RADIUS rfc. http://wiki.freeradius.org/RFC
> good from a deployment pov too. We'd have to be OK with
supporting only
> LDAP as a kdb backend though i suppose.
>
>
> | 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.
>
> Agreed.
>
>
> | 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.
>
> For not having to loop over the tl_data list? What do you think would
> be a good way of presenting it to the plugin?
The easiest way would be a generic struct in struct _krb5_db_entry_new
which has an enum which indicates the backend type and a pointer which
points to the additional backend specific data. I don't know if MIT will
like this idea.
>
> | 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.
>
> This is exactly how I'm doing it, except I'm doing it by hand for now.
> Thanks for the nice script!
>
> _______________________________________________
> authhub-devel mailing list
> authhub-devel(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/authhub-devel
_______________________________________________
authhub-devel mailing list
authhub-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/authhub-devel
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
4767
days inactive
4768
days old
authhub-devel@lists.fedorahosted.org
9 comments
4 participants
participants (4)
-
Dmitri Pal -
Fredrik Thulin -
Linus Nordberg -
Sumit Bose