I've got network with Windows 2003 servers and Active Directory
installed. Workstations are mostly mobile users who take their laptops
home during the night, and return the next day to work at the office.
All laptops have two general accounts created, one local and one
domain account. The local account is for the users to work on when at
home, while the domain account is for them to use when in the office.
I'm now looking into a solution that will 'force' the user to log into
the domain account when in the office, not allowing him to access the
local account for security reasons.
I've been searching for a clear answer, but there seems to be some
type of confusion on the topic.
If anyone can provide any suggestions or point me toward sources which
contain information that allow me to perform the above, it would be
highly appreciated!
Thanks again,
--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-
* http://sl.mvps.org * http://msmvps.com/blogs/sp *
"Chris P" <ch...@firewall.cx> wrote in message
news:1179558886.5...@q23g2000hsg.googlegroups.com...
Thanks for your suggestion, but I think I need to provide more
information so you can understand what the needs are here, and why I
need to implement the above:
The idea behind the usage of two separate accounts on each user's
laptop is more of a practical sense.
The local (laptop) account will be used when the user is at home. The
user has the ability to install applications he might want to use at
home. This gives him the ability to work with the machine almost
without limitations. The local user account will be part of the 'Power
Users' of the local machine.
The domain account is to be used only for work. The user won't be able
to install any programs that are not related to his working
environment. The domain user has no additional privileges to install
or change settings under the domain account - restricting considerably
how much he can do, that's not related to his work.
I need to figure a way to force the user log into his domain account
when he connects his laptop at the office, not allowing him access to
the local computer account.
As a side note, I've been also looking into 802.1x, which looks
promising, but the problem with it is that when enabled, it works for
all accounts on the laptop. As an alternative, if I could enable
802.1x only when the user is logged into his domain account (locally
cached as you mentioned), then he can enter his username / password
and gain access to the network. If he logs into the local user account
and the 802.1x is disabled for that account, he can't join the
network.
Your thoughts and comments are appreciated.
The problem I see with what you just presented is that the user has an
account on the machine where they can pretty much do what they want. This
could lead to all sorts of interesting problems.
Also - as far as them 'only being able to logon at work with a domain
account'... well...
I can bring the machine into work - already logged in - connect to your
network and map the network resources using the NET USE command and my
domain credentials already.
I can log into my other account anywhere and more than likely figure out how
to modify my other account (unless - perhaps even if - you are using roaming
profiles) and add all sorts of neat things that the account will have access
to.
Not to mention I have physical access and time with the laptop and a valid
account with extra privs already. It's like a key that is just a little
off - I can likely still 'bump' my way in. I can likely do some things and
make myself a full-on admin on the machine - make my domain user a full-on
admin on the machine - etc.
In other words - you aren't creating much of a separate environment anyway.
If they can install things on the machine - the other users can be given
rights to run it by them as well.
--
Shenan Stanley
MS-MVP
--
How To Ask Questions The Smart Way
http://www.catb.org/~esr/faqs/smart-questions.html
As the others have told you - and everyone does understand what you want
to do - your plan is flawed. You will not get any security by doing what
you plan and you will open your corporate network to viruses and other
malware. Just because you have separate user accounts (one domain, one
local) on a computer does not protect against complete infection. If you
allow your users free rein locally, then it will be only a matter of
time (probably very short) before you're looking at a complete redo of
your corporate network, including servers.
The answer is to have only an administrator and possibly a tech
(administrative) account locally and not give those passwords to the
users. Users should have no local logon on company workstations. They
can use cached credentials if they need to use their machines at home.
Malke
--
Elephant Boy Computers
www.elephantboycomputers.com
"Don't Panic!"
MS-MVP Windows - Shell/User
I just do not see what you plan is accomplishing. The users can
bring into work a laptop that has become junked out, infested
with any kind of hijackware, keylogger, etc.. Those malware do
no care what account logs in, except in so far as different accounts
can provide more and less access to network resources. Etc..
Slav stated the solution most succintly. Do not provide the local
account. When they are not in the office they can log in with the
cached domain login. If they cannot install whatever they might
wish then you do have a chance at a controlled (i.e. safe) machine
environment for them to get their work done.
In so far as I am aware there is no built-in solution to your stated
need, i.e. to be network aware and control login rights based on
that network awareness. You can however create a login script
that tests for some things, based on which it is highly probably it
will always decide correctly whether it is in the office network
or not, and immediately log off any account that is logging in
(i.e. running the script) that is not a domain account. Now, if
you did that, and made sure that only Administrators, not just
Power Users, could affect the login script, then I would come
into the office, not connect to the network, log, then connect to
the network.
Roger
"Chris P" <ch...@firewall.cx> wrote in message
news:1179575728.8...@n59g2000hsh.googlegroups.com...