Hi guys to day we faced a new issue with windows server 2003 AD , Old password will still be used for one hour after changing to new password. Reasons are given below
Below is the snap shot of a article having info about use of old password:
To reliably support network access for NTLM network authentication in distributed environments, Windows Server 2003 SP1 modifies the NTLM network authentication behavior as follows:
After a domain user successfully changes a password by using NTLM, the old password can still be used for network access for a user-definable time period. This behavior allows accounts, such as service accounts, that are logged on to multiple computers to access the network while the password change propagates.
Reference : http://support.microsoft.com/kb/906305
The article details how to change the behavior. Its a registry change, which our servers don't have. And if they are missing the setting, then they default to 60 minutes.
Note : This behavior does not cause a security weakness. As long as only one user knows both passwords, the user is still securely authenticated by using either password.
C u in next post
Venky
Thursday, March 19, 2009
Tuesday, March 17, 2009
Factory Pattern
Factory Pattern
The factory design pattern is very simple. Several other patterns, like the abstract factory pattern, build off of it though, so it is a common base pattern. You use this pattern when one or more of the following are true:
1. A class can't anticipate the class of object it must create.
2. A class wants its subclasses to specify the objects it creates.
3. Classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate.[GOF108]
The class is easy to implement and consists of an identifier, either named constants or an enum and a switch statement. For our example we will be creating dog objects. As with any good OO design we start with an interface for our related objects.
The IDog interface
Code:
public interface IDog
{
void Bark();
void Scratch();
}
We just define a couple of simple methods for our dogs to do.
Now for the two actual concrete dog classes. We define a bulldog and poodle class:
Code:
public class CPoodle : IDog
{
public CPoodle()
{
Console.WriteLine("Creating Poodle");
}
public void Bark()
{
Console.WriteLine("Yip Yip");
}
public void Scratch()
{
Console.WriteLine("Scratch Scratch");
}
}
public class CBullDog : IDog
{
public CBullDog()
{
Console.WriteLine("Creating Bulldog");
}
public void Bark()
{
Console.WriteLine("Wooof Wooof");
}
public void Scratch()
{
Console.WriteLine("Scratch Slobber Scratch");
}
}
Now for our factory class. It’s static and contains one method to return the correct dog.
Code:
public class CDogFactory
{
public enum DogType
{
Poodle,Bulldog
}
static CDogFactory()
{
}
public static IDog CreateDog(DogType TypeOfDog)
{
switch (TypeOfDog)
{
case DogType.Bulldog:
return new CBullDog();
case DogType.Poodle:
return new CPoodle();
default:
throw new ArgumentException("Invalid Dog Type!");
}
}
}
We make the class static so we don’t need an instance of the class.
To test the class, I have created a simple function. Our test function just return the dogs and uses them. In a more real world app, the type of dog would have been determined by the user or through program logic.
Code:
IDog dog1;
IDog dog2;
dog1 = CDogFactory.CreateDog(CDogFactory.DogType.Bulldog);
dog2 = CDogFactory.CreateDog(CDogFactory.DogType.Poodle);
dog1.Bark();
dog1.Scratch();
dog2.Bark();
dog2.Scratch();
The factory design pattern is very simple. Several other patterns, like the abstract factory pattern, build off of it though, so it is a common base pattern. You use this pattern when one or more of the following are true:
1. A class can't anticipate the class of object it must create.
2. A class wants its subclasses to specify the objects it creates.
3. Classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate.[GOF108]
The class is easy to implement and consists of an identifier, either named constants or an enum and a switch statement. For our example we will be creating dog objects. As with any good OO design we start with an interface for our related objects.
The IDog interface
Code:
public interface IDog
{
void Bark();
void Scratch();
}
We just define a couple of simple methods for our dogs to do.
Now for the two actual concrete dog classes. We define a bulldog and poodle class:
Code:
public class CPoodle : IDog
{
public CPoodle()
{
Console.WriteLine("Creating Poodle");
}
public void Bark()
{
Console.WriteLine("Yip Yip");
}
public void Scratch()
{
Console.WriteLine("Scratch Scratch");
}
}
public class CBullDog : IDog
{
public CBullDog()
{
Console.WriteLine("Creating Bulldog");
}
public void Bark()
{
Console.WriteLine("Wooof Wooof");
}
public void Scratch()
{
Console.WriteLine("Scratch Slobber Scratch");
}
}
Now for our factory class. It’s static and contains one method to return the correct dog.
Code:
public class CDogFactory
{
public enum DogType
{
Poodle,Bulldog
}
static CDogFactory()
{
}
public static IDog CreateDog(DogType TypeOfDog)
{
switch (TypeOfDog)
{
case DogType.Bulldog:
return new CBullDog();
case DogType.Poodle:
return new CPoodle();
default:
throw new ArgumentException("Invalid Dog Type!");
}
}
}
We make the class static so we don’t need an instance of the class.
To test the class, I have created a simple function. Our test function just return the dogs and uses them. In a more real world app, the type of dog would have been determined by the user or through program logic.
Code:
IDog dog1;
IDog dog2;
dog1 = CDogFactory.CreateDog(CDogFactory.DogType.Bulldog);
dog2 = CDogFactory.CreateDog(CDogFactory.DogType.Poodle);
dog1.Bark();
dog1.Scratch();
dog2.Bark();
dog2.Scratch();
Subscribe to:
Posts (Atom)