Re: ADAM Proxy Authentication and Movetree

Tech-Archive recommends: Fix windows errors by optimizing your registry

Thanks Lee. Our end state in production over the next month is to replace
the separate domain trusts with one single forest trust, which should buy us
exactly what we need. We went with that configuration in development and UAT
because production would indeed look the same, but that's taken longer to
happen than expected. Having the separate domain trusts in the interim had
seemingly bought us the exact benefits of a single forest trust, at least up
until this point.

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
will hold users outside our corporate environment. That client domain should
not be trusted by our corporate domains and will not live inside our main
forest. The ADAM domain will trust it however.

We do have a plan in place to reprovision users to ADAM with MIIS who have
been migrated using movetree, but that is planned for a later phase. The
users acquire organizational memberships, application rights, and other
ancillary data not suited for AD in ADAM after they are provisioned, so the
reprovisoning process will require that all that ADAM data is retained and
reapplied after reprovisioning, which will take some time.

Thanks again,

Jason

"Lee Flight" wrote:

> 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

  • Re: creating one way trust
    ... of different forest. ... It sounds for me that you do not need/have a trust, ... Once everything is replicated from the win2k svr. ... Let me try to understan a little more about youre network. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Huge AD deployment
    ... That was the case in Windows 2000, but in Windows Server 2003 forest trusts ... note though is that a forest trust is only transitive for domains within the ... >> company.com in that data center and have every country trust company.com ... instead of going over the internet. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Domain Functional Levels and Trusts
    ... other type of trust, i.e., Forest Trust ... A Forest Trust and an External trust are TWO DISTINCT types ... FORESTS to be in Win2003 Forest Functional Level. ... External trusts are possible in any MODE, ...
    (microsoft.public.windows.server.active_directory)
  • RE: Two way forest trust fails only in one direction
    ... After deep research of the SMB signing, we saw that both servers need Reg Key: ... needed to match on both servers on both sides of the trust. ... B's Forest, but Company B can not access Company As forest at all. ... running DNS and WINS under Windows Active Directory. ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADAM Proxy Authentication and Movetree
    ... trust in place from the outset for this to work and that possible ... Move ADAM into the forest where users live. ... >> yet to be upgraded to Windows Server 2003. ...
    (microsoft.public.windows.server.active_directory)