Re: ADAM Proxy Authentication and Movetree

Hi

that might be worth investigating.

As I said domain migration scenarios are outside my ken but I have asked the
experts and what I am hearing is that you would need to have had a forest
trust in place from the outset for this to work and that possible
resolutions
are:

" 1. Move ADAM into the forest where users live.
Or
2. Recreate proxies to point to the new SIDs."

If you have MIIS in place then option 2. might be a more automatic
approach.

Hope that helps
Lee Flight

"Jason" <Jason@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:050B34BF-4A16-4908-A519-231470F59445@xxxxxxxxxxxxxxxx
> After further thought, SID filtering came to mind as a possible reason for
> authentication issue after movetree. I'm going to test the theory in our
> lab
> and will post the results.
>
> "Jason" wrote:
>
>> Both the legacy domain and the new domain are in the same
>> forest...they're
>> both child domains of a root placeholder domain. The ADAM domain is in a
>> seprate forest, but a trust has been setup between the ADAM domain and
>> all
>> domains in the other forest that users are provisioned from. Eventually
>> those trusts will be replaced with a single forest trust, but the other
>> forest is still in mixed mode because a few of the domain controllers
>> have
>> yet to be upgraded to Windows Server 2003.
>>
>> I should note that the setup has worked well for us overall. We have
>> close
>> to 50k users provisioned to ADAM via MIIS as user proxies. Users who
>> have
>> been provisioned and never movetree'd are working fine.
>>
>> "Lee Flight" wrote:
>>
>> > Hi
>> >
>> > could you clarify
>> >
>> > are the legacy domain and new domain in the same forest?
>> >
>> > where does the ADAM server sit, in which, if any of the above domains?
>> >
>> > Thanks
>> > Lee Flight
>> >
>> > "Jason" <Jason@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> > news:B5EA0409-4644-4219-985D-6B6CFC9DD4E7@xxxxxxxxxxxxxxxx
>> > > We are in a parallel production at the moment and are not fully live,
>> > > which
>> > > turns out to be a good thing. We tested simple binds against user
>> > > proxies
>> > > that had been migrated in development and UAT, which worked, so I'm
>> > > at a
>> > > loss
>> > > as to why this is happening in production.
>> > >
>> > > It doesn't seem relevant, but could other entries in sidHistory be
>> > > causing
>> > > this to occur? The other thing common to these users is they have an
>> > > additional SID in sidHistory for old NT4 account access, but these
>> > > older
>> > > SIDs
>> > > are scheduled to be removed 90 days after the migration. I believe
>> > > the
>> > > NT4
>> > > accounts are still around and enabled, but I doesn't seem like that
>> > > would
>> > > cause a problem.
>> > >
>> > > As far as the GC is concerned...I checked that querying a GC from the
>> > > ADAM
>> > > servers returned the sidHistory for these users with no issues.
>> > >
>> > > "Lee Flight" wrote:
>> > >
>> > >> Hi
>> > >>
>> > >> has the simple bind to a user proxy ever worked for a migrated user
>> > >> in your production network?
>> > >>
>> > >> I do not know much about migration scenarios but I believe that both
>> > >> ldp and ADAM use LsaLookupSids under the covers and for that to
>> > >> work with sidHistory would seem to require that the lookup to take
>> > >> place
>> > >> against a GC for the forest that contains the domains. I guess you
>> > >> could
>> > >> check
>> > >> the user objects in the GC to make sure that they have the correct
>> > >> sidHistory.
>> > >>
>> > >> Lee Flight
>> > >>
>> > >>
>> > >> "Jason" <Jason@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> > >> news:3E5A75DC-CAA2-438A-9A52-86F703D6B4B9@xxxxxxxxxxxxxxxx
>> > >> > We are currently experiencing an issue with the early stages of a
>> > >> > production
>> > >> > ADAM deployment that have not been seen in our development
>> > >> > environment.
>> > >> >
>> > >> > Essentially, user proxies are provisioned to ADAM via MIIS based
>> > >> > upon
>> > >> > our
>> > >> > business rules. A few times a month, a migration team has been
>> > >> > utilizing
>> > >> > movetree to move some AD accounts already provisoned to ADAM from
>> > >> > a
>> > >> > legacy
>> > >> > domain to a new corporate domain. When MIIS picks up on the
>> > >> > change, it
>> > >> > sees
>> > >> > the movetree events as renames and handles everything accordingly.
>> > >> > The
>> > >> > objectSids of the ADAM users who have been migrated do not change
>> > >> > in
>> > >> > ADAM,
>> > >> > but the users can still be bound to has movetree has preserved the
>> > >> > old
>> > >> > user's
>> > >> > objectSid in the sidHistory of the new user.
>> > >> >
>> > >> > In development, we tested this migration path from the legacy
>> > >> > domain to
>> > >> > the
>> > >> > new domain extensively to ensure it was feasible. We never had
>> > >> > any
>> > >> > problems,
>> > >> > but lately have been getting intermittent reports in production of
>> > >> > migrated
>> > >> > users not being able to bind to ADAM. We have verified that the
>> > >> > sidHistory
>> > >> > is intact on the new domain users after movetree, but proxy
>> > >> > authentication
>> > >> > via encrypted simple bind has ceased functioning. We have also
>> > >> > tried
>> > >> > disabling the requirement for encrypted proxy authentication just
>> > >> > to
>> > >> > rule
>> > >> > that out. Negotiate authentication works however, which is
>> > >> > strange.
>> > >> >
>> > >> > To dig deeper, the "Sid lookup" utility in ldp is unable to locate
>> > >> > the
>> > >> > migrated users when their old objectSid is specified, and when
>> > >> > security
>> > >> > auditing of failure events is enabled on the ADAM servers, an
>> > >> > error of
>> > >> > 0xC0000064 is being logged, which maps to NT_STATUS_NO_SUCH_USER,
>> > >> > but
>> > >> > an
>> > >> > AD
>> > >> > user clearly exists that holds the old objectSid in its
>> > >> > sidHistory.
>> > >> >
>> > >> > At this point, we're unsure as to how we can further troubleshoot
>> > >> > the
>> > >> > issue.
>> > >> > Does anyone have any suggestions or ideas as to why this may be
>> > >> > occurring?
>> > >> >
>> > >> > Thanks,
>> > >> >
>> > >> > Jason
>> > >> >
>> > >>
>> > >>
>> > >>
>> >
>> >
>> >


.

Relevant Pages

  • Cross Forest Trusts
    ... production versions of Windows Server 2003. ... to establish forest to forest trusts, ... Both boxes have the forest functional level raised to ...
    (microsoft.public.windows.server.active_directory)
  • Re: Joining two domains
    ... if both are w2k3 with forest functional level windows server 2003 you CAN ... or you can always create an external trust ... BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx ...
    (microsoft.public.win2000.active_directory)
  • RE: windows 2008 dc and trust
    ... I would advise you upgrade the Windows Server 2003 DCs to Windows Server 2008 ... the forest and domain functional level to W2K8 R2 taking advantage of the new ... it should not affect the the trust relationship with the other domain. ... raise the forest - domain functional level to Windows Server 2008 R2. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Multiple Forests Trust
    ... Forest A and Forest B ... All domains Domain Functional Level are 'Windows Server 2003' ... I had built a Forest Trust. ... when I logon from domain rose.net's computer, ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADAM Proxy Authentication and Movetree
    ... the separate domain trusts with one single forest trust, ... The reason our ADAM cluster is in a separate forest is mainly because we ... will also be provisioning users to ADAM from an external client domain which ...
    (microsoft.public.windows.server.active_directory)
Loading