[Freeipa-users] Integrating Yubikey tokens into FreeIPA

[Rich Megginson]

On 12/19/2012 07:04 AM, Simo Sorce wrote:
> On Wed, 2012-12-19 at 13:32 +0000, Dale Macartney wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> On 12/19/2012 01:20 PM, Simo Sorce wrote:
>>> On Wed, 2012-12-19 at 12:30 +0000, Dale Macartney wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Morning all
>>>>
>>>> Heres something I was working on last night with Gavin Spurgeon.
>>>>
>>>> If anyone would like to comment on better ways to achieve this, i'd love
>>>> to here it so I can update my own procedures (and the article of course)
>>>>
>>>>
>> https://www.dalemacartney.com/2012/12/19/integrating-yubikey-token-details-within-ldap-with-freeipa-and-red-hat-enterprise-linux-6/
>>>> I hope some people find it useful.
>>> Hi Dale,
>>> what problem do you have adding new schema ?
>> we weren't able to add any objectIdentifier fields... when trying to
>> search for existing schema entries, we received the below output.
>>
>> [root at ds01 ~]# ldapsearch -LLL -h localhost -D "cn=Directory Manager" -x
>> -w redhat123 -b "cn=schema"
>> dn: cn=schema
>> objectClass: top
>> objectClass: ldapSubentry
>> objectClass: subschema
>> cn: schema
>
> For some reason the attribute you need to list are not returned by
> default and needs to be explicitly listed, they are treated as
> operatrional.
In LDAPv3, operational attributes are not returned by default - they 
must be explicitly specified.
>
> The search you need is:
> ldapsearch -h localhost -x -b "cn=schema" "attributeTypes,objectClasses"
ldapsearch -h localhost -x -b "cn=schema" "objectclass=*" \* 
attributeTypes objectClasses

Also note that the lines will be wrapped, so if you are trying to grep 
for something, you will have to unwrap the lines first - see
http://richmegginson.livejournal.com/18726.html
>
> Note that you do not need any auth to read the schema by default.
>
>> [root at ds01 ~]#
>>
>>
>> We were trying to use this schema which what created by Michal, however
>> we never managed to get it imported with the objectidentifier values there.
>>
>> dn: cn=yubikey,cn=config
>> objectClass: SchemaConfig
>> cn: yubikey
>> #
>> # YubiKey LDAP schema
>> #
>> # Author: Michal Ludvig<michal at logix.cz>
>> # Consider a small PayPal donation:
>> #         http://logix.cz/michal/devel/yubikey-ldap/
>> #
>> # Common Logix OID structure
>> #<LogixOID>.<Project>.<SNMP/LDAP>.<...>
>> ObjectIdentifier: {0}logixOID        1.3.6.1.4.1.40789
>> ObjectIdentifier: {1}YubiKeyPrj    logixOID:2012.11.1
>> ObjectIdentifier: {2}YkSNMP        YubiKeyPrj:1
>> ObjectIdentifier: {3}YkLDAP        YubiKeyPrj:2
>> # YubiKey schema sub-tree
>> ObjectIdentifier: {4}YkAttribute   YkLDAP:1
>> ObjectIdentifier: {5}YkObjectClass YkLDAP:2
>> AttributeTypes: {0}( YkAttribute:1
>>    NAME 'yubiKeyId'
>>    DESC 'Yubico YubiKey ID'
>>    EQUALITY caseIgnoreIA5Match
>>    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} )
>> ObjectClasses: {0}( YkObjectClass:1
>>    NAME 'yubiKeyUser'
>>    DESC 'Yubico YubiKey User'
>>    SUP top
>>    AUXILIARY
>>    MAY ( yubiKeyId ) )
>>
>> we ended up having to settle for
>>
>> dn: cn=schema
>> #
>> attributeTypes: ( 1.3.6.1.4.1.40789.2012.11.1.2.1 NAME 'yubiKeyId' DESC
>> 'Yubico YubiKey ID' EQUALITY caseIgnoreIA5Match SYNTAX
>> 1.3.6.1.4.1.1466.115.121.1.26{1
>> objectClasses: ( 1.3.6.1.4.1.40789.2012.11.1.2.2 NAME 'yubiKeyUser' DESC
>> 'Yubico YubiKey User' SUP top AUXILIARY MAY ( yubiKeyId ) )
>>
>>
>> Is there any security restrictions on the schema or perhaps something
>> done differently to normal LDAP? Unless of course I'm doing something silly.
>>
>> thoughts?
> Ah no it's just that 389ds does not support the prettified OIDs yet. The
> schema file you ended up importing is 100% equivalent to the one with
> the OID prefix substitutions.
>
> Simo.
>