|
Posted by ANIXIS on September 27, 2006, 4:46 am
Please log in for more thread options Roger, what you say is correct for GINA DLLs, but not password filters.
Password filters should continue to work with Longhorn server unless
Microsoft decides to depreciate the interface. They have not done so
yet, and I don't see why they would as it doesn't exhibit the same
problems as the GINA interface.
Roger Abell [MVP] wrote:
> A small added mention I'll make that either route, with cards
> or Gina, a sizable cost or/and effort can come from remaining
> one domain-ensional for account differentiations.
>
> Without having account (policy) distinctions aligned on intra-forest
> boundaries, forest design for authN must invest in careful coding
> work or a capability/convenience/cost analysis of Gina products.
> If you are considering going these routes I would strongly advise
> you to also review Longhorn server innovations and the obsoleting
> of the Gina extension model. Vendor choice via their future design
> for support could after all, make a valid selector criterion. :-) -
>
> Roger
>
> > Can we have 2 sets of domain password policy? Or we can use Block Policy
> > Inheritance and Disable No Override option to achieve this.
> >
> > Any suggestion for best Domain Password Policy pratice? Modify the default
> > Domain Policy GPO or create a new Password GPO and linked to the root
> > container?
> >
> > If we implement a secure password policy now, what may happen to the
> > existing users? Are they offered a chance to change their password when
> > they
> > first log in? How about those laptop mobile VPN users?
> >
|