Hi all,
When our Smoothwall was first installed in the school (Feb 2014), we set up the following group structure within our AD:
AD Security Group "Pupils" - contained an explicit list of all student accounts in the school
AD Security Group "students2013" - contained an explicit list of all student accounts for intake for that specific year
AD Security group "Year 7" - contained just the AD Security Group "students2013" (i.e. "nested")
AD Security Group "Key Stage 3" - contained the AD Security Groups "Year 7", "Year 8" and "Year 9" (i.e. "double-nested")
(and same for all Year Groups and the 3 Key Stages)
So, to clarify, the Key Stage groups contained no explicit student accounts - just nested groups. Easy to manage - each year we just needed to update the membership of the "Year x" group to align with the relevant "studentsxxxx" group, and all other groups would update accordingly. And excellent granularity for use in Firewall rules....
In Smoothwall, we mapped, within our AD integration:
AD Security Group "Year 7" to Smoothwall Local Group "Year 7"
AD Security Group "Key Stage 3" to Smoothwall Local Group "Key Stage 3"
AD Security Group "Pupils" to Smoothwall Local Group "All Students"
We then created Firewall/Guardian Rules based on the above hierarchy - so that, for example, we could add an explicit permit to the rule for "Key Stage 5", which would give access to a specific Website to 6th Form Students, but not the rest of the school student population. Or we could grant temporary access to a Website (perhaps a gaming site for one lesson) for just Year 8, etc.
But the above is no longer working. All Students are only being categorised by Smoothwall only as a member of the group "Pupils" (which is, of course, the only group that has a full, explicit list of student accounts - no nested groups).
So, can I throw this out there - is there anyone else using nested groups within AD, and mapping said groups to Smoothwall Local Groups...?
I would really welcome any positive confirmation that someone else has, or more importantly is, using nested groups successfully in this manner....
I realise that a lot of school implementations may more simply have a couple of groups, such as "All Staff" and "All Students" (or indeed have granular groups, but perhaps with explicit lists of student accounts in them - with a potentially higher management overhead?) - but the simplicity of group management, and the granularity that this approach provides to us is really useful in demonstrating, for example, the use of technology in safeguarding - it's not always appropriate to permit Year 7's to have access to Websites that Year 13's need to get to.
Of course - if anyone *not* using nested groups would like to consider the above hierarchy and do any tests between their Smoothwall and their AD, that would be great...
Thanks,
All I can say is, it never did matter - it always worked fine. Firewall/Guardian rule order is least granular down to most granular, e.g. along the lines of: All Students - Explicit Allows All Students - Explicit Blocks Key Stage 5 - Explicit Allows Key Stage 5 - Explicit Blocks Year 13 - Explicit Allows Year 13 - Explicit Blocks (Plus all other Key Stage and Years, in hierarchical order, down to) Year 7 - Explicit Allows Year 7 - Explicit Blocks When looking at the Smoothwall realtime log, Smoothwall always (at installation) listed the student as being a member of all 3 mapped groups, and per design would permit or block based on the first firewall rule applicable to any of the 3 groups (i.e. first match) - but now the realtime logs clearly only show the student being a member of the "All Students" group - and of course if it isn't "seeing" the student as a member of any of the other groups, the Firewall rules that include those more granular groups become (have become...) redundant....