| Author | Messages | |
DWyatt@xxxx.yyy
 | | 07/26/2006 3:39 AM |
| I'd be interested to
hear peoples strategy for permissioning windows based file servers when the
server is in a Windows 2003 domain. I have read the best practices about
putting users into global groups then put the global groups into local groups
then permission the resource with the local group.
But:
1. Is it
better practice to put the domain local group into a local group on the
file server and then use this local group to permission the share/folder?
Is this excessive? I have read something about performance or avoiding
limits by using the server local group when the access token is
created.
2. What
shortcomings would there be in putting users into global groups then simply
permissioning the global group onto the resource. We only have a single
forest/domain.
I am also aware of
Universal groups but lets put these to one side.....for the
moment..;-)
Thanks
David
****************************************************************************
This message contains confidential information and is intended only
for the individual or entity named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the contents of this
message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version.
This message is provided for informational purposes and should not
be construed as an invitation or offer to buy or sell any securities or
related financial instruments.
GAM operates in many jurisdictions and is
regulated or licensed in those jurisdictions as required.
****************************************************************************
| | | |
| solinear@xxxx.yyy
| | 07/26/2006 4:38 AM |
| On 7/26/06, Wyatt, David wrote:
I'd be interested to
hear peoples strategy for permissioning windows based file servers when the
server is in a Windows 2003 domain. I have read the best practices about
putting users into global groups then put the global groups into local groups
then permission the resource with the local group.
But:
1. Is it
better practice to put the domain local group into a local group on the
file server and then use this local group to permission the share/folder?
Is this excessive? I have read something about performance or avoiding
limits by using the server local group when the access token is
created.
2. What
shortcomings would there be in putting users into global groups then simply
permissioning the global group onto the resource. We only have a single
forest/domain.
I am also aware of
Universal groups but lets put these to one side.....for the
moment..;-)
Thanks
David
****************************************************************************
This message contains confidential information and is intended only
for the individual or entity named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the contents of this
message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version.
This message is provided for informational purposes and should not
be construed as an invitation or offer to buy or sell any securities or
related financial instruments.
GAM operates in many jurisdictions and is
regulated or licensed in those jurisdictions as required.
**************************************************************************** | | | |
| solinear@xxxx.yyy
| | 07/26/2006 5:09 AM |
| I'd be interested to
hear peoples strategy for permissioning windows based file servers when the
server is in a Windows 2003 domain. I have read the best practices about
putting users into global groups then put the global groups into local groups
then permission the resource with the local group.
But:
1. Is it
better practice to put the domain local group into a local group on the
file server and then use this local group to permission the share/folder?
Is this excessive? I have read something about performance or avoiding
limits by using the server local group when the access token is
created.
2. What
shortcomings would there be in putting users into global groups then simply
permissioning the global group onto the resource. We only have a single
forest/domain.
I am also aware of
Universal groups but lets put these to one side.....for the
moment..;-)
Thanks
David
****************************************************************************
This message contains confidential information and is intended only
for the individual or entity named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the contents of this
message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version.
This message is provided for informational purposes and should not
be construed as an invitation or offer to buy or sell any securities or
related financial instruments.
GAM operates in many jurisdictions and is
regulated or licensed in those jurisdictions as required.
**************************************************************************** | | | |
| danholme
Posts:139
| | 07/27/2006 1:57 AM |
| Local groups are so 1990s ¦
because they exist on individual systems, they are virtually un-manageable
(save via Restricted Groups policies). Fugghedaboutem.
DOMAIN LOCAL groups are what you probably mean, or should mean.
They exist as a single instance in Active Directory, instead of the
multiple-local-groups-one-each-server model of NT4.
The best practice in a SINGLE DOMAIN (or a single ˜active™
domain with an empty forest root domain) is:
Users à Global Groups - - - >
Global Groups à Domain Local Groups - - - > Domain Local Groups à ACL
Users go into global groups (which in Windows Server 2000 or
greater domain functional level can be further nested into other global groups if
necessary).
Global groups nest into domain local groups.
ACLs are assigned to domain local groups.
In a multidomain forest, best practice is the above *OR*
Users à Global Groups - - - >
Global Groups à Universal Groups - - - > Universal Groups à Domain
Local Groups - - - > Domain Local Groups à ACL
Or
Users à Global Groups | Universal
Groups à ACL
Universal groups are really useful in multidomain forests for
defining things like My Company Executives where each domain has
a (global) Executives role defined, and those nest into a ˜super group™
WHY this complexity? It yields optimal replication (though that™s
more of a technicality these days, in a single domain, since many/most
organizations are making every DC a global catalog server). More importantly,
it sets you up for effective role-based management in a dynamic enterprise.
Domain Local Groups as the access group enable cross-domain
access which may not seem important to you today (˜we have just one
domain™) but will become important the day there™s a joint venture,
acquisition, merger, etc¦ If it seems to complex to figure out the why
then stop asking and just do it ;-)
There is no *technical* better or worse
about ACLing resources to global groups. For that matter, you could ACL
resources to each and every user. Why don™t you do that? Because it™s
obviously unmanageable. Doing it to global groups is equally, if
not as obviously, unmanageable, particularly in the long term. That said,
there™s a very minor technical difference that deals with the size of
your PAC in your Kerberos ticket, so please don™t take me to the matt for
not detailing that¦ it™s technical more than practical. What
should be driving your design is the need for ROLE BASED MANAGEMENT of your
enterprise.
Role based management, as far as resources goes,
should be discussed in terms of Roles (people / groups of people) and
Management (in this case, managing access to a resource). Roles define
who someone is “ you could ˜describe™ them by their roles
(job, function, department, business unit, geographical location, seniority, etc.).
Just so happens that roles should be defined using global security groups and
yes, roles nest within roles (global à global) so your departmental
management role groups might very well nest into a ˜corporate managers™
role group. Say, for example, that you define your brokers as to whether they
are ˜just brokers™ (global group: ROLE_Brokers) or ˜supervisors™
(ROLE_Broker_Sups). Let™s say you also have a team of auditors
(ROLE_Auditors)
Management groups (for dealing with resource access, in this
case) are typically domain local groups. But don™t think of them as
their technical scope (domain local) “ think of them as their purpose: to
manage access to a resource. So, for example, if you have a share for your broker
data, you might have the following resource access management groups that
parallel specific access levels to that share:
Ø ACL_BrokerData_Editors (ACL
= a group for access control; Editors = MODIFY permission)
Ø ACL_BrokerData_Contributors
(Contributors = permissions to create new files/folders and to modify own
creations; but read-only to other people™s stuff)
Ø ACL_BrokerData_Readers (Read
access)
With those three ˜resource access™ groups, you can manage
access to that resource by defining which roles get what access.
Nest your role groups into your management groups. (global Ã
domain local, technically). So your business might lead you to say brokers
can add things to this share and read but not modify other people™s stuff.
That would be nesting Role_Brokers into ACL_BrokerData_Contributors.
Role_Broker_Sups might be given ˜modify™ permission by nesting them
into ACL_BrokerData_Editors. And your auditors might be nested into the
ACL_BrokerData_Readers group.
You are now headed towards ROLE BASED MANAGEMENT. When an
employee is promoted from broker to supervisor, you change their role
membership (out of Role_Brokers, into Role_BrokerEditors) and voila, they now
have access to this (and other) data store(s) based on the new role™s
access. Ideally, you tie your role groups to your HR system so that any change
to roles of an employee are ˜authoritative™.
Finally, think about the ease-of-audit. If you™ve been
disciplined about (or have provisioned shares by) tying ACLs ONLY to your ˜resource
management™ (ACL_xyz) groups, you can now find out who has access
to this resource by enumerating group membership, rather than going out
and hunting through ACLs on files/folders. Even more useful if that BrokerData
happens to be folders on several servers! You can also easily identify
the exceptions to the rule in your organization by looking at ACL
groups and identifying any security principal that is not a ROLE_
group¦! Very powerful stuff.
So focus on the BUSINESS of managing groups¦ why
you want to manage groups. I expect it will be because you want more
manageability of people, resources, security, configuration, software
deployment, blah blah blah¦ role based management. If you can describe
your business in terms of roles (people / groups of people (other roles)) and
what you are trying to manage (people, resources, security, configuration,
software deployment, blah blah blah) you™ll have done 90% of the work.
THEN you can turn to group scope and here™s the bottom line: roles are
global; management groups are domain local unless you are managing
something using Group Policy security filtering (which can only be done to
global groups).
I™m doing a lot of work with role based management these
days, and I™d be happy to help you out more where I can: dan dot holme
at intelliem dot com is my email. I don™t check this group often enough,
so feel free to write me directly.
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Wyatt, David
Sent: Wednesday, July 26, 2006 8:28 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: [ActiveDir] Domain Local Groups vs Global Groups
I'd
be interested to hear peoples strategy for permissioning windows based file
servers when the server is in a Windows 2003 domain. I have read the best
practices about putting users into global groups then put the global groups
into local groups then permission the resource with the local group. But:
1.
Is it better practice to put the domain local group into a local group on
the file server and then use this local group to permission the
share/folder? Is this excessive? I have read something about
performance or avoiding limits by using the server local group when the access
token is created.
2.
What shortcomings would there be in putting users into global groups then
simply permissioning the global group onto the resource. We only have a
single forest/domain.
I
am also aware of Universal groups but lets put these to one side.....for the
moment..;-)
Thanks
David
****************************************************************************
This message contains confidential
information and is intended only
for the individual or entity named. If you
are not the named addressee
you should not disseminate, distribute or
copy this e-mail.
Please notify the sender immediately by
e-mail if you have received
this e-mail by mistake and delete this e-mail
from your system.
E-mail transmission cannot be guaranteed to
be secure or error-free
as information could be intercepted,
corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The
sender therefore does not
accept liability for any errors or omissions
in the contents of this
message which arise as a result of e-mail
transmission.
If verification is required please request a
hard-copy version.
This message is provided for informational
purposes and should not
be construed as an invitation or offer to buy
or sell any securities or
related financial instruments.
GAM operates in many jurisdictions and is
regulated or licensed in those jurisdictions
as required.
**************************************************************************** | | | |
| danholme
Posts:139
| | 07/27/2006 2:08 AM |
| That™s what I get for reading my inbox up¦ David: do read my
treatise in my earlier email.
But Matt Hargraves response did raise the one technical issue
I only alluded to: token size. He™s right to raise a ˜flag™ about Exchange.
Depending on the complexity of your role-based design and
whether you use Exchange (2003 or 2000; 2007 seems to be exempt from this
issue) and your Exchange architecture, you do have to watch for the number
of total groups a user belongs to. A large number of group memberships will
reduce the effective ˜maximum users per exchange server™ level somewhat¦ but
whether that ˜somewhat™ would be salient depends on several factors.
To tie together what Matt discussed and what I proposed, my
discussion lays out a design that integrates both RBS and ABS. You definitely
want role-based management. Whether you also go to the level I outlined of
managing ACLs depends on your environment: more resources; more complex
security; and more ˜spread out™ resources and you™ll be better served by the
design I described. In a simpler environment (e.g. we have a departmental
share with each department having a subfolder on the extreme side), you don™t
necessarily need the ABS layer.
Dan
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Wyatt, David
Sent: Wednesday, July 26, 2006 8:28 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: [ActiveDir] Domain Local Groups vs Global Groups
I'd
be interested to hear peoples strategy for permissioning windows based file
servers when the server is in a Windows 2003 domain. I have read the best
practices about putting users into global groups then put the global groups
into local groups then permission the resource with the local group. But:
1.
Is it better practice to put the domain local group into a local group on
the file server and then use this local group to permission the
share/folder? Is this excessive? I have read something about
performance or avoiding limits by using the server local group when the access
token is created.
2.
What shortcomings would there be in putting users into global groups then
simply permissioning the global group onto the resource. We only have a
single forest/domain.
I
am also aware of Universal groups but lets put these to one side.....for the
moment..;-)
Thanks
David
****************************************************************************
This message contains confidential
information and is intended only
for the individual or entity named. If you
are not the named addressee
you should not disseminate, distribute or
copy this e-mail.
Please notify the sender immediately by
e-mail if you have received
this e-mail by mistake and delete this e-mail
from your system.
E-mail transmission cannot be guaranteed to
be secure or error-free
as information could be intercepted,
corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The
sender therefore does not
accept liability for any errors or omissions
in the contents of this
message which arise as a result of e-mail
transmission.
If verification is required please request a
hard-copy version.
This message is provided for informational
purposes and should not
be construed as an invitation or offer to buy
or sell any securities or
related financial instruments.
GAM operates in many jurisdictions and is
regulated or licensed in those jurisdictions
as required.
**************************************************************************** | | | |
| solinear@xxxx.yyy
| | 07/27/2006 5:36 AM |
| That's what I get for reading my inbox "up"¦ David: do read my
treatise in my earlier email.
But Matt Hargraves response did raise the one technical issue
I only alluded to: token size. He's right to raise a 'flag' about Exchange.
Depending on the complexity of your role-based design and
whether you use Exchange (2003 or 2000; 2007 seems to be exempt from this
issue) and your Exchange architecture, you do have to watch for the number
of total groups a user belongs to. A large number of group memberships will
reduce the effective 'maximum users per exchange server' level somewhat¦ but
whether that 'somewhat' would be salient depends on several factors.
To "tie together" what Matt discussed and what I proposed, my
discussion lays out a design that integrates both RBS and ABS. You definitely
want role-based management. Whether you also go to the level I outlined of
managing ACLs depends on your environment: more resources; more complex
security; and more 'spread out' resources and you'll be better served by the
design I described. In a simpler environment (e.g. "we have a departmental
share with each department having a subfolder" on the extreme side), you don't
necessarily need the ABS layer.
Dan
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Wyatt, David
Sent: Wednesday, July 26, 2006 8:28 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: [ActiveDir] Domain Local Groups vs Global Groups
I'd
be interested to hear peoples strategy for permissioning windows based file
servers when the server is in a Windows 2003 domain. I have read the best
practices about putting users into global groups then put the global groups
into local groups then permission the resource with the local group. But:
1.
Is it better practice to put the domain local group into a local group on
the file server and then use this local group to permission the
share/folder? Is this excessive? I have read something about
performance or avoiding limits by using the server local group when the access
token is created.
2.
What shortcomings would there be in putting users into global groups then
simply permissioning the global group onto the resource. We only have a
single forest/domain.
I
am also aware of Universal groups but lets put these to one side.....for the
moment..;-)
Thanks
David
****************************************************************************
This message contains confidential
information and is intended only
for the individual or entity named. If you
are not the named addressee
you should not disseminate, distribute or
copy this e-mail.
Please notify the sender immediately by
e-mail if you have received
this e-mail by mistake and delete this e-mail
from your system.
E-mail transmission cannot be guaranteed to
be secure or error-free
as information could be intercepted,
corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The
sender therefore does not
accept liability for any errors or omissions
in the contents of this
message which arise as a result of e-mail
transmission.
If verification is required please request a
hard-copy version.
This message is provided for informational
purposes and should not
be construed as an invitation or offer to buy
or sell any securities or
related financial instruments.
GAM operates in many jurisdictions and is
regulated or licensed in those jurisdictions
as required.
**************************************************************************** | | | |
| DWyatt@xxxx.yyy
| | 07/27/2006 9:43 AM |
| Matt /
Dan - great posts from both of you and this has provided some good material to
start planning.
Thanks
-David
-----Original Message-----From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Matt HargravesSent: 27 Jul 2006
6:36To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: Re:
[ActiveDir] Domain Local Groups vs Global GroupsThere are
some considerations when you get to multidomain forests:Domain Global
groups can only contain user or global group objects from the domain they
actually reside within. In other words, if your global group resides
within corp.company.com then you can
have *only* members that are within the corp.company.com domain. They can be
members of local groups in any other domain or universal groups anywhere
within the forest though. They also will not allow universal or domain
local group memberships. Thus, if you're going to have a multidomain
forest, you will need to make sure that your role-based groups are inside your
user domain and that you use those groups to sit in task-based groups (Domain
Local groups). If all your DCs are also GCs (which there really is very
little reason for them not to be, since you lose a good amount of performance
by forcing authentication to go to a DC then to a GC to create a token -- if
it can all be done on one machine, save yourself some headache later in life
and make all your DCs GCs also). Universal groups are useful when you
have groups that will be utilized to ACL items everywhere in the environment
and no matter where the user resides, they will need that membership
utilized. All Distribution List groups are automatically Universal, if I
recall correctly. Universal groups can only contain users, global groups
or universal groups from anywhere in the forest (or outside the forest).
Local groups can have memberships of just about any type of object, no
matter where it resides within the forest. However, you can only ACL
items in a particular domain with a Domain Local group if that group resides
in the same domain as the resource. There are a few different basic
formats for multidomain forests...User/Exchange domain, resource
domain(s). The nice thing about this model is that you only have
role-based groups in your User/Exchange domain, so group memberships are
relatively low and the Exchange Servers don't have much of a problem with
their paged pool memory. You'll usually run into other barriers on your
Exchange box before you run out of paged pool memory with this model.
User domain, Exchange domain, Resource domain(s). I'm not really
sure why anyone uses this model other than a lack of understanding of how
tokens are created. Same as the above example, but you get to buy more
DCs and your tokens in Exchange are probably actually larger than they would
be in the above example. Multiple user/resource domains, single
Exchange domain. Again, I think that this is another example of people
who don't understand token creation.... same reasons as the immediately
preceding example. Unless you have a lot of resources being accessed
across domains (and cross domain memberships), you're probably just better off
with a single forest root/domain structure than wasting money on extra DCs in
this model. Then there is the standard single forest root/domain model
that smaller companies go with. This has the wonderful elegance of
simplicity. For the mostpart there is little reason to debate between
global, universal and local groups other than making sure that you don't
create local groups and try to nest them within global groups. For the
mostpart, a security group is a security group is a security group in this
model. You can ACL items with them and with the exception of nesting,
there isn't a whole lot that you can do with one that you can't do with
another. For more information about how a token is created, download
the doc at the bottom of the following page:http://www.microsoft.com/downloads/details.aspx?FamilyID=22dd9251-0781-42e6-9346-89d577a3e74a&DisplayLang=enFor
more information on the differences between group types, go to:http://technet2.microsoft.com/WindowsServer/en/library/79d93e46-ecab-4165-8001-7adc3c9f804e1033.mspx?mfr=trueGoing
back to the conversations from before though, try and make sure that you
actually create a good RBS model and *use* it. There is no reason to
create a bunch of global groups for users (a site RBS group set, a job RBS
group set, and a hierarchy RBS group set) then not using them and nesting all
your users in every other global group you create. This conversation
has gotten probably way more complex than you expected... hehe.That
being said, I also like a combination RBS/ABS model myself. Use
role-based groups to create your 'general' access to items and then when
people who are outside those basic security groups, add them into ABS security
groups for that resource. There are a few problems with this model in
that you end up with a *lot* of groups, but the benefit is that your security
model is able to adapt to the needs of the environment instead of making the
environment adapt to your security model. You don't make your web
servers run with IIS turned off because it's a security vulnerability, you
just keep them in a DMZ or limit them to not being able to go outside the
internal network. Don't make your security model limit your environment
either. 10,000 empty groups aren't going to significantly affect your
environment and if you have 64-bit DCs, 100,000 (or 1,000,000) empty security
groups won't significantly impact your environment, so don't hesitate to have
them in place so that if you need them, you can use them instead of running
around in circles when you *do* find you need them. Do a little work now
and save yourself some work later.... do both, but consider the role-based
groups to be the preferred path.
On 7/26/06, Dan
Holme dan.holme@xxxxxxxxxxxxx>
wrote:
That's what I get
for reading my inbox "up"¦ David: do read my treatise in my earlier
email.
But Matt Hargraves
response did raise the one technical issue I only alluded to: token
size. He's right to raise a 'flag' about Exchange.
Depending on the
complexity of your role-based design and whether you use Exchange
(2003 or 2000; 2007 seems to be exempt from this issue) and your
Exchange architecture, you do have to watch for the number of total groups a
user belongs to. A large number of group memberships will reduce the
effective 'maximum users per exchange server' level somewhat¦ but whether
that 'somewhat' would be salient depends on several factors.
To "tie together"
what Matt discussed and what I proposed, my discussion lays out a design
that integrates both RBS and ABS. You definitely want
role-based management. Whether you also go to the level I outlined of
managing ACLs depends on your environment: more resources; more complex
security; and more 'spread out' resources and you'll be better served by the
design I described. In a simpler environment (e.g. "we have a
departmental share with each department having a subfolder" on the extreme
side), you don't necessarily need the ABS layer.
Dan
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto: ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of
Wyatt, DavidSent: Wednesday, July 26, 2006 8:28
AMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject:
[ActiveDir] Domain Local Groups vs Global Groups
I'd be interested to hear peoples strategy
for permissioning windows based file servers when the server is in a Windows
2003 domain. I have read the best practices about putting users into
global groups then put the global groups into local groups then permission
the resource with the local group. But:
1. Is it better practice to put
the domain local group into a local group on the file server and then use
this local group to permission the share/folder? Is this
excessive? I have read something about performance or avoiding limits
by using the server local group when the access token is
created.
2. What shortcomings would there be
in putting users into global groups then simply permissioning the global
group onto the resource. We only have a single
forest/domain.
I am also aware of Universal groups but
lets put these to one side.....for the moment..;-)
Thanks
David
****************************************************************************
This message
contains confidential information and is intended only
for the
individual or entity named. If you are not the named addressee
you should not
disseminate, distribute or copy this e-mail.
Please notify
the sender immediately by e-mail if you have received
this e-mail by
mistake and delete this e-mail from your system.
E-mail
transmission cannot be guaranteed to be secure or error-free
as information
could be intercepted, corrupted, lost, destroyed, arrive
late or
incomplete, or contain viruses. The sender therefore does not
accept liability
for any errors or omissions in the contents of this
message which
arise as a result of e-mail transmission.
If verification
is required please request a hard-copy version.
This message is
provided for informational purposes and should not
be construed as
an invitation or offer to buy or sell any securities or
related
financial instruments.
GAM operates in
many jurisdictions and is
regulated or
licensed in those jurisdictions as required.
****************************************************************************
| | | |
|
|