Force local policies

[travisr]

I'm far from being an IT guy, so excuse me if it sounds like I don't
know what I'm talking about. Anyway, as I understand it, a computer on
a domain will always override local policies with domain policies, if
the policy exists on the domain. What I would like to achieve is to
allow users to add the XPe installation to a domain but still guarantee
enforcement of certain local policies. Does anybody know if there is
any way to achieve this? If not, perhaps this is something somebody
from Microsoft might want to take under consideration - it may not make
sense for a PC but for an embedded product it certainly does.

Also, if it isn't possible to ensure local policies are retained, can
anybody tell me how to disable the ability to add a system to a domain
without sacrificing other networking capabilities. Thanks in advance.

 

[KM]

travisr,

I'm far from being an IT guy, so excuse me if it sounds like I don't
know what I'm talking about. Anyway, as I understand it, a computer on
a domain will always override local policies with domain policies, if
the policy exists on the domain. What I would like to achieve is to
allow users to add the XPe installation to a domain but still guarantee
enforcement of certain local policies. Does anybody know if there is
any way to achieve this?

I don't know any way how to force local policies over domain ones unless it is set up on the server side. Although I am not an IT
guy either and therefore not an expert in this.
It does make sense, however, that domain policies are always on top of the local ones. Otherwise, corporate (domain) users would be
able to set up thier workstation as they wish and easy break administring and maintating the network.

If not, perhaps this is something somebody
from Microsoft might want to take under consideration - it may not make
sense for a PC but for an embedded product it certainly does.

I disagree. If you connect your embedded product to a network (and, worse, your product runs *PC* software) it must obey to the
network rules set up by administrators of that network. You want to join a domain, you will have to use the domain rules. This is my
opinion.

Also, if it isn't possible to ensure local policies are retained, can
anybody tell me how to disable the ability to add a system to a domain
without sacrificing other networking capabilities. Thanks in advance.

Well, not quite sure what networking capabilities you are interested in?
After all, you can always remove Join Domain component from your config and that will break the device ability to login to a domain.
Networking would work as it did before you removed the component. Some domain related stuff, of course, wouldn't work.

 

[steves]

Disclaimer: I too, am not an IT expert. However, i do have an opinion
.

I believe all of the policies can be compiled into .pol or .adm files,
which could be distributed to the domain administrators involved.
Then, they create what is called an "organizational unit" in the domain
(Think 'department', like 'accounting', engineering', and 'embedded
whatzamajigs'.) This way, the domain can be set up to be sure that
your instrument has the appropriate required policies.

Philisophically I tried to use the minimum policy set that I could.
There is a very small set of policies that I don't want messed with,
such as disabling windows update, and disabling task manager.

However, I know that my customers have a fairly wide range of security
tolerance in their various organizations (we build a medical device).
Some customers have enforced password changes, password complexity
rules, restricted logins based on the scheduled work hours, and all
manner of very strict rules. Others set up the instrument to
automatically login and forget about it. So, it is really the domain
administrator that is in control of this situation.

So, to restate, I would recommend that you define the absolute minimum
policy settings that you need (saved as .pol files), and recommend that
during installation an organizational unit or user group be created for
the devices, which contains your required policy settings.

This is a drag, and complicates the installation process, but I'm
afraid that that is the nature of the beast. As for the option of NOT
joining the domain, that will work. However, if you are in an
environment that requires individual login (HIPAA, a medical records
law, requires this), then you have just complicated the domain admins'
job, because he now has to manage user accounts on your device
separately from the rest of the network. If your environment allows
the machine to auto log in as a single username, then not joining the
domain is probably an OK option.

Steves
StevesATeyeDASHimagingDOTcom.

 

[travisr]

I agree that a device should follow the network rules of a domain but
there are some policies that don't affect how the device interacts with
the network (like 'look and feel' options) where it would be nice if
that could be retained on an embedded device. Regardless, as I've
learned more about the extent to which domain policy can control the
user interface and behavior I've decided we should probably just
completely eliminate domain support for our device. To accomplish
this, I believe you referred to excluding the 'Netlogon/Netjoin'
component - but a dependency trail can be traced from this back to
'FBA: SCE' and then 'Windows Logon (Standard)'. Does anybody know if
it is safe to exclude the 'Netlogon/NetJoin' component despite these
dependencies?

 

[KM]

travisr,

I agree that a device should follow the network rules of a domain but
there are some policies that don't affect how the device interacts with
the network (like 'look and feel' options) where it would be nice if
that could be retained on an embedded device. Regardless, as I've

Well.. I am still no with you here.
E.g., well-known 'look&feel' related policies of Explorer to provide user access to some system folders or, even more, hide/show
some drives. This is often used in domain environments by administrators as a way to protect workstations from a mess that end user
might be able to easy create if he'd have access to the system drives and folders. If local policies came first, domain
administrators wouldn't have a way to protect the network from "curious users".
I believe that for an embedded device if certian functionality is not required it should be removed, not disabled by a policy or
etc.
Or, as Steves pointed out, it is always a good option to create an exception for a set of [embedded] devices and give the network
administrators the policy set you're looking for those devices. Then they, the administrators, would be in control of the things
there as it should be in domain environment.

learned more about the extent to which domain policy can control the
user interface and behavior I've decided we should probably just
completely eliminate domain support for our device. To accomplish
this, I believe you referred to excluding the 'Netlogon/Netjoin'

Yes, that's what I meant. This component is responsible for joining your target computer to a domain.

component - but a dependency trail can be traced from this back to
'FBA: SCE' and then 'Windows Logon (Standard)'. Does anybody know if
it is safe to exclude the 'Netlogon/NetJoin' component despite these
dependencies?

Yup, it is safe to remove this component if you have no plans on joining a domain from the target.
In fact, we've got a bunch of network enabled images without that component included.

--
=========
Regards,
KM

 

[travisr]

Steves,
Thanks for the input. We're in the same boat as we are also working
with a medical device and trying to satisfy HIPAA. As I look at the
1000+ policies that might be enforced by a domain it's a bit daunting
to try and consider which will policies we need to account for in
specifying how our device behaves. What have you done to ensure that
joining the device to a domain does not have any unfavorable
consequences? Who's fault is it if a device is installed at a site and
a screensaver pops up 15 minutes into a monitoring session because the
domain specifies that it should? Even if we provide a set of policies
for our device on a domain, it seems like we can't guarantee that they
will be applied by the network admin and as such we can't guarantee a
pre-defined behavior for the system.

 

[travisr]

Thanks for the help. I'm not saying that all local policies should
always be allowed to override domain policies - particularily not on
PCs. I'm just saying that as an embedded developer, it would be nice
if we could specify some local policies that aren't overridden when the
device is joined to a domain. Then Steves wouldn't have to distribute
a set of policies and hope the admin actually uses them. I'd like to
be able to say "This is how the device behaves" and know that it won't
change regardless of whether it's on a domain or not.

travisr,

I agree that a device should follow the network rules of a domain but
there are some policies that don't affect how the device interacts with
the network (like 'look and feel' options) where it would be nice if
that could be retained on an embedded device. Regardless, as I've

Well.. I am still no with you here.
E.g., well-known 'look&feel' related policies of Explorer to provide user access to some system folders or, even more, hide/show
some drives. This is often used in domain environments by administrators as a way to protect workstations from a mess that end user
might be able to easy create if he'd have access to the system drives and folders. If local policies came first, domain
administrators wouldn't have a way to protect the network from "curious users".
I believe that for an embedded device if certian functionality is not required it should be removed, not disabled by a policy or
etc.
Or, as Steves pointed out, it is always a good option to create an exception for a set of [embedded] devices and give the network
administrators the policy set you're looking for those devices. Then they, the administrators, would be in control of the things
there as it should be in domain environment.

learned more about the extent to which domain policy can control the
user interface and behavior I've decided we should probably just
completely eliminate domain support for our device. To accomplish
this, I believe you referred to excluding the 'Netlogon/Netjoin'

Yes, that's what I meant. This component is responsible for joining your target computer to a domain.

component - but a dependency trail can be traced from this back to
'FBA: SCE' and then 'Windows Logon (Standard)'. Does anybody know if
it is safe to exclude the 'Netlogon/NetJoin' component despite these
dependencies?

Yup, it is safe to remove this component if you have no plans on joining a domain from the target.
In fact, we've got a bunch of network enabled images without that component included.