Re: ADAM Proxy Authentication and Movetree
- From: "Jason" <Jason@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 20 Sep 2005 08:15:03 -0700
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
> >
>
>
>
.
- Follow-Ups:
- Re: ADAM Proxy Authentication and Movetree
- From: Lee Flight
- Re: ADAM Proxy Authentication and Movetree
- Prev by Date: Re: deleting printers
- Next by Date: Re: trust relationships ...
- Previous by thread: Re: Raise domain functional level
- Next by thread: Re: ADAM Proxy Authentication and Movetree
- Index(es):
Relevant Pages
|
Loading
