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<[email protected]>
# 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
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-users
