Re: Authentication for non-domain computers
- From: "Mike Shepperd" <mikesmobile_|_gmail>
- Date: Wed, 6 Jul 2005 11:34:06 -0700
You're right, that does present a problem... I'd have them connect to a
terminal server in the domain which will allow the password change as well
as an interactive logon, but your environment may not allow for that. If it
does not, then I'd remove the reqiurement for them to change their password,
though that introduces a security issue. The only other thing that comes to
mind would be if they have e-mail accounts and you use OWA, they might be
able to utilize that for the password changes...
--
--
Mike Shepperd
MCSE NT4, 2000, 2003
NewFuture Consulting
Seattle, Washington
"Hugh" <Hugh@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:7DA748A9-7284-4CDA-A429-85A52102F326@xxxxxxxxxxxxxxxx
> Thanks for the reply. In this scenario, how would they be able to change
> their password - especially for the initial connection where it is set by
> the
> admins to require a change when they logon? If they can't, this presents
> a
> problem.
>
> --
> Hugh
>
>
> "Mike Shepperd" wrote:
>
>> 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
>>
>>
>>
.
- Follow-Ups:
- Re: Authentication for non-domain computers
- From: Paul Williams [MVP]
- Re: Authentication for non-domain computers
- References:
- Authentication for non-domain computers
- From: Hugh
- Re: Authentication for non-domain computers
- From: Mike Shepperd
- Re: Authentication for non-domain computers
- From: Hugh
- Authentication for non-domain computers
- Prev by Date: Re: does anyone have a conf_public.xml for AD synchronization?
- Next by Date: Re: Workgroup vs. AD
- Previous by thread: Re: Authentication for non-domain computers
- Next by thread: Re: Authentication for non-domain computers
- Index(es):
Relevant Pages
|
