Is there a clever (or preferred) way to organize users and groups in FotoWeb?
In many Active Directory hierarchies, we see that administrators group people by the organizational department they're part of. This can (but may not always) prove a challenge with FotoWeb, since more fine grained access control is required. The suggestion and example below offers a potential solution to this, by expanding on the departmental approach in a way that makes the system more manageable to the FotoWeb administrator without upsetting the domain administrators. Read on to learn how!
Instead of just mapping departments to groups, as is often the case in a regular Active Directory setup, it may be a good idea to also create groups that represent people based on their roles - which resources they can access and what they're allowed to do with them. That way, it will be possible to add existing AD groups (representing departments) to the groups that represent roles. This approach also does away with the necessity of having to manually reorganize the structure on the user level.
- Group:Album users (has access to create albums)
- Group: Album sharing (has access to share albums)
- The existing AD Group Marketing is a member of the Album users and the Album sharing group, but does not have explicit album rights on its own.
Tip: Roles can be modeled directly using AD groups or using groups that only exist in FotoWeb but have AD groups as members. Individual users from the AD can also be added to such a role group.
Why is this so important?
Understanding roles helps you have fewer groups to deal with in the FotoWeb access lists. That's a good thing as the system expands as you won't have to rethink the entire structure of things as user adoption increases.
A possible caveat (and key to solving it)
The following scenario may pose a challenge, so a solution has been suggested further down.
- Group A has access to "apples"
- Group B has access to "oranges"
- A user who is a member of both groups should have access to "apples or oranges", but attempting to do things this way will not work.
- Create a new GroupAB and make it a member of Group A and Group B.
- Give GroupAB access to "apples or oranges"
- Make sure the access list entry for GroupAB comes before the ones of Group A and Group B in the archive access list.