LDAP, FreeRadius, and Schema
Hi all, I was wondering what everyone uses for an account objectClass? Right now I'm using "Person", which makes the dn: cn=<user>,ou=Radius,dc=mydomain,dc=net However, indexing the cn would index the CN of other OU's as well ... . I'm just wondering what people use. I know "Account" could also be used. Regards, Matt
Hi all,
I was wondering what everyone uses for an account objectClass? Right now I'm using "Person", which makes the dn:
cn=<user>,ou=Radius,dc=mydomain,dc=net
However, indexing the cn would index the CN of other OU's as well ... .. I'm just wondering what people use. I know "Account" could also be used.
I extend my schema with RADIUS-LDAPv3.schema and use the radiusprofile objectclass. However, mine is old and uses uid instead of cn, which is in that file. You certainly could create your own objectclass or modify the one that is there. I think you should stick with cn, since that is what freeradius knows and you already use it. It will make maintanence and upgrades much easier. However, back to your problem. I don't see what the issue is with indexing cn. If you are ever going to do searches on other OU's for a cn attribute, you would probably hope that its indexed. The performance hit you will take for indexing that attribute is probably not even close to the performance gain you will get having cn indexed for searches. This is especially true with the newest versions of openldap (2.3). Dusty Doris
I extend my schema with RADIUS-LDAPv3.schema and use the radiusprofile objectclass. However, mine is old and uses uid instead of cn, which is in that file. You certainly could create your own objectclass or modify the one that is there. I think you should stick with cn, since that is what freeradius knows and you already use it. It will make maintanence and upgrades much easier.
However, back to your problem. I don't see what the issue is with indexing cn. If you are ever going to do searches on other OU's for a cn attribute, you would probably hope that its indexed. The performance hit you will take for indexing that attribute is probably not even close to the performance gain you will get having cn indexed for searches.
This is especially true with the newest versions of openldap (2.3).
Dusty Doris
Well, most of our email accounts are in a different organizational unit, and they use posixAccount (so based off of uid). However, our radius organizational unit is separate ... and I'm now using type "account" with cn's. You're saying this is ok? The only reason I was complaining about indexing is because in the organizational unit that managed the email accounts uses the cn value for full name .... so I was indexing the full name without being needed.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
!DSPAM:438dc37f9891662219514!
Well, most of our email accounts are in a different organizational unit, and they use posixAccount (so based off of uid). However, our radius organizational unit is separate ... and I'm now using type "account" with cn's. You're saying this is ok? Its probably fine.
The only reason I was complaining about indexing is because in the organizational unit that managed the email accounts uses the cn value for full name .... so I was indexing the full name without being needed.
That's ok. Your just indexing with eq anyway, correct? If you were doing substring indexes as well it would be a little more load, but I usually err on the side of having too much indexed. But we run pretty good sized ldap servers anyway.
participants (3)
-
Dusty Doris -
Matt Juszczak -
Matthew Juszczak