The core of your problem here is that you seem to be trying to use interfaces to describe what a class is, rather than it's functionality. An interface is best use to specify things such as IAuthorizeable or IEnumerable. They indicate varying behavior on a common theme.
For cases like yours, as others have suggested, you want to use inheritance unless you can change how you structure things. My preference would be to create a user class which contains strategies for the parts that vary, rather than inheriting.
There's a large difference between inheriting shared features and allowing differences to be extendable. If you compose User with interfaces rather than create base classes, if more roles need to be added in the future, you only have to add another implementation of the changing behavior, rather than making another subclass that may share different things with the other two classes.
An example:
class User
{
private IAuthenticator authenticator;
public string Name { get; set; }
public Guid Id { get; set; }
public User(string name, Guid id, IAuthenticator authenticator)
{
Name = name;
Id = id;
this.authenticator = authenticator;
}
public Rights Authenticate()
{
return authenticator.Authenticate(Name, Id);
}
}
Where the authenticators could be things like:
public class WebAuthenticator : IAuthenticator
{
public Rights Authenticate(string name, Guid id)
{
// Some web specific authentication logic
}
}
And Rights:
[Flags]
public enum Rights
{
None = 0, Read = 1, Write = 1 << 1, Execute = 1 << 2
}
The end result is that your code is reusable, extensible, and flexible. Generally the fact that a user is an administrator should not give the user class extra logic, but rather constrain things that use the specific instance.