This answer has been updated for UML 2.5.1 specification.
First, it appears that the notation is valid.
Actors (18.2.1) can only have Associations to UseCases, Components, and Classes and these Associations must be binary.
The relationship between Admin and User is Generalization (defined in 9.9.7). It is a specialization of the DirectedRelationship (defined in 7.8.5) which is a specialization of Relationship (defined in 7.8.15). The specializations of Relationship are DirectedRelationship and Association (defined in 11.8.1). This means that a Generalization is not an Association.
The Actor puts restrictions on what a valid Association is. However, the definition of Actor does not restrict other relationships, so we need to look through the hierarchy of definitions to determine if a Generalization is valid.
Actor is a specialization of a BehavioredClassifier (10.5.1). None of the defined Association Ends covers this case, so we need to keep looking. A BehavioredClassifier is a specialization of a Classifier (10.5.1.3). One of the Association Ends of a Classifier is Generalization. Because a Classifier allows for Generalization between Classifiers and an Actor is a Classifier without further restriction on the Generalization, the relationship appears to be valid.
I'd like to note that there is no example diagram that shows a Generalization relationship between two Actors. Also, there is no discussion in the text (that I could find) about this relationship. The only way to learn about it is to follow the formal definitions of Actor, Association, and Generalization all the way through their hierarchy.
The next thing to look at is if this diagram would make sense to a reader.
Formally, Use Cases are described in Section 18 of the UML spec - a Use Case is a set of behaviors that a system offers, and this set of behaviors can also include variations (and variations include, but are not limited to exceptional behavior and error handling). Informally, a use case is "a list of actions or event steps typically defining the interactions between a role and a system to achieve a goal".
As a reader, if I saw the diagram without any explanatory text, I would make the assumption that the behavior defined by the Authenticate use case was the same for both Admin and User. After all, both have a relationship to the same set of behaviors called Authenticate. I would not expect a single symbol on a diagram to denote two different sets of event steps.
In UML, Use Cases can be related to each other, such as by the Extends and Includes relationships along with Generalization. These can be used to modify the behavior of a Use Case.
I believe that you can express everything that you want to express in a UML Use Case diagram. However, I'm not convinced that the example, as presented in the question, is the best way of communicating the information to interested parties.
My preference would be to generally avoid use case diagrams. Instead, I would a favor one of a number of textual or tabular methods for capturing use cases, relating them to each other, and extracting common steps or information shared across use cases to a single location. This is similar to advice provided by Martin Fowler in UML Distilled.
If you strong feel that a use case diagram is needed, I would look at how I represent the Authenticate use case to make it more clear that there are actually two different flows. I believe that there are a few different options here that all conform to the specification.