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@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@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<mic...@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.


_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to