Unless there's a different method that I'm missing, there would just
be too many groups to do this manageably with. I need to store pairs
of values from a list of about 20 from one group (locations), and 50
from another (roles), from which any combinations are possible, and
they have to be associated, they don't mean anything in isolated
context without the other. The only way I could think to do this with
groups would be to create a 20x50 matrix (1000 cells) for "location
a, role a" ... "location a, role b" ... "location g, role h", etc. I
don't want to manage 1000 security groups, as well as possibly being
in a position of having to create more and repopulate things when new
elements are added to the possible values.
If there's a different way to approach this, I'm open to it, but so
far Frank's solution seems to be the cleanest, and I did produce a
workable test of this yesterday under AD. It means I have to parse
the values of the pairs at the application level, which is a bit more
work, but I'm going on the understanding that there's no way to have
value pairs within LDAP.
The other possibility I was considering was to have a new object type
for a "location role", with a location code, a role code, and an
employee ID to map back to the person record, but the fact that each
of these would have to have a unique DN seemed redundant and wasteful
- really, the DN could itself contain all of the data, since it would
basically be a primary key, so you'd have a structureless object like
"employeeID=12345,cn=location_a,cn=role_d,cn=people,dc=foo,dc=org"
without any actual content? That didn't make much sense to me when I
was thinking of it, but I know I still have SQL and relational tables
on the brain with this method, and this approach doesn't seem to make
much sense from what I understand about LDAP. If there's a way to do
it this way, though, I'm also open to considering it - in some ways,
it would be easier because less application-level parsing would be
required to retrieve the information, and queries could play a bigger
role...
On Nov 2, 2007, at 10:08 AM, Dustin Puryear wrote:
Unless I'm missing something this is best solved using group
membership.
Why are we forcing an attribute for this? The only reason I'd use the
attribute method is if I needed to support unknown values, which
doesn't
seem to be the case here.
--
Puryear Information Technology, LLC
Baton Rouge, LA * 225-706-8414
http://www.puryear-it.com
Author, "Best Practices for Managing Linux and UNIX Servers"
http://www.puryear-it.com/pubs/linux-unix-best-practices
Identity Management, LDAP, and Linux Integration
Steve Linberg wrote:
On Oct 31, 2007, at 6:53 PM, Frank Swasey wrote:
Steve,
You are absolutely correct that LDAP is very flat and goes out of
its
way to tell you not to count on order of values.
That being said, what the developers have done when they cared about
order was to use a "list" type attribute. Take a look at the
postalAddress attribute which takes a list of values separated by
"$"
characters.
So, your example of
fooRole: location_a $ role_a
fooRole: location_b $ role_b
would be the way to go.
This sounds exactly like what I need. Thanks very much.
Cheers,
Steve
--
Steve Linberg, Chief Goblin
Silicon Goblin Technologies
http://silicongoblin.com
Be kind. Remember, everyone you meet is fighting a hard battle.
---
You are currently subscribed to [email protected] as: [EMAIL PROTECTED]
it.com]
To unsubscribe send email to [EMAIL PROTECTED] with the word
UNSUBSCRIBE as the SUBJECT of the message.
--
Steve Linberg, Chief Goblin
Silicon Goblin Technologies
http://silicongoblin.com
Be kind. Remember, everyone you meet is fighting a hard battle.
---
You are currently subscribed to [email protected] as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the
SUBJECT of the message.
