Re: Authentication for non-domain computers

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

When trying to access a resource the contractors should be prompted for
credentials. The most convenient, but least secure solution is to have them
connect to the resource once and save their username and password. It will
then be presented for that resource when they try to connect in the future
and should only fail once they've changed their password in AD, then they'll
need to enter the new one the next time they access the resource and save
the new password.

Unless you have somehow prevented fallback to NTLM by locking down your
domain, most likely in Group Policy (won't apply to the contractors, but
will apply on your servers), they should try to access a resource and the
server should see that the client supports NTLM v2 (most likely) and
negotiate security using NTLM, prompting for the username/password.

--
--
Mike Shepperd
MCSE NT4, 2000, 2003
NewFuture Consulting
Seattle, Washington


"Hugh" <Hugh@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:9D2B322A-44C2-4903-8CF9-F1034EA6249C@xxxxxxxxxxxxxxxx
> We are in the process of allowing contractors into our network via a Cisco
> VPN solution. The contractors will access a "SecureNet" area only, which
> is
> separate from our production network. The SecureNet will also contain
> development servers upon which the contractors will work. The SecureNet
> will
> also contain an LDAP proxy, which will allow authentication to our
> production
> AD environment without direct access to any domain controllers.
>
> The contractors will be using their own computers, which will not be
> "joined" to our domain - thus, the computers will have no Kerberos
> password.
> The contractors will, however, have AD user accounts. In this scenario,
> how
> can we authenticate these users? Keep in mind that this is not a
> web/browser
> scenario. Their computers will need to directly access NTFS partitions.
>
> We have considered a separate forest for the SecureNet, but prefer the
> proxy
> approach to reduce administrative overhead, assuming we can resolve this
> issue.
>
> Thanks in advance.
> --
> Hugh


.

Relevant Pages

  • Re: Authentication for non-domain computers
    ... In this scenario, how would they be able to change ... > connect to the resource once and save their username and password. ... > domain, most likely in Group Policy (won't apply to the contractors, but ... The SecureNet will also contain ...
    (microsoft.public.windows.server.active_directory)
  • Re: Authentication for non-domain computers
    ... terminal server in the domain which will allow the password change as well ... >> connect to the resource once and save their username and password. ... >> domain, most likely in Group Policy (won't apply to the contractors, but ... The SecureNet will also contain ...
    (microsoft.public.windows.server.active_directory)
  • Authentication for non-domain computers
    ... We are in the process of allowing contractors into our network via a Cisco ... The contractors will access a "SecureNet" area only, ... We have considered a separate forest for the SecureNet, ...
    (microsoft.public.windows.server.active_directory)
  • Re: Resource Types Report: Employees vs Contractors in a given month
    ... trying to count the number of tasks that contractors are doing versus ... I assigned the resources to tasks and used the Resource Work Summary ... It is easy to add the Group field to the Pivot table data. ... When you summarize the data, the total contractor number come out to ...
    (microsoft.public.project)
  • Re: Resource allocation across multiple projects
    ... I'm quite low on the org chart, so the managers and contractors don't ... overallocated because I have left the resource units at 100%. ... fellow MVP, Mike Glen's series on Project lessons and techniques. ...
    (microsoft.public.project)