An anoynous user cannot get tickets at all, if you try this is the result:

kinit -n
ipa user-find
ipa: ERROR: Major (851968): Unspecified GSS failure.  Minor code may provide more information, Minor (2529638924): KDC policy rejects request

However if you first obtain and use some other credentials, ipa client will be tricked in believing the anonymous user has access to the server:

kinit admin
ipa user-find
[output]
kinit -n
ipa user-find
[output]

And this is what you'll find in the kernel keyring:

# keyctl list @s
3 keys in keyring:
796820056: --alswrv     0 65534 keyring: _uid.0
899919707: --alswrv     0     0 user: ipa_session_cookie:WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS
1008844158: --alswrv     0     0 user: ipa_session_cookie:admin@EXAMPLE.TEST

However this is what klist will show:

 klist
Ticket cache: KEYRING:persistent:0:krb_ccache_BBatySv
Default principal: WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS

Valid starting       Expires              Service principal
12/08/2016 22:07:48  12/09/2016 22:07:48  krbtgt/EXAMPLE.TEST@EXAMPLE.TEST

NOTE: there is no HTTP ticket for the anonymous user.

What happened ?
The anonymous user was not used for the connection, instead the admin credentials stored in the ccache collection where used as the admin previously obtained a valid HTTP cookie.
However the client libraries missed this fact and stored the admin cookie in an ipa_session keyring key under the anonymous user principal name.

This is confusing and should be avoided. Note that this is not really a security issue because the actual user performing the operations on the system is the same user and no other user on the system can use these credentials. But an admin may be confused.

The ipa cli code should probably verify which ccache has an actual HTTP ticket and use the cacche principal name as the owner of the session cookie.