Well first let's say exactly what it does.
When you check this box, you can type in a username, which is a junk username, so let's say we entered "anon".
Then, it takes the value of the username you enter when you log in (or have saved in the profile) and chops off everything before the
'@' in that username, and puts the contents of the textbox there instead. So if you log in as me@realm.com, it will replace
that with anon@realm.com.
So first rule: ONLY use this when your username is of the form username@realm.domain. (On other operating systems, where
this is usually called the "anonymous identity" this restriction does not apply and you can set the entire value of the anonymous
identity independently from the username. The above behavior is a microsoft-only constraint.)
So at this point anon@realm.com is used as the username in the EAPOL conversation across the open-system WiFi layer.
If someone is sniffing packets, either on wireless or sniffing RADIUS packets on the other side of the NAS, this is what they will
see. Your actual username (me@realm.com) is only used inside encrypted tunnels.
So second rule: If you do not care that any random individual can collect a list of your usernames and their MAC addresses, don't
bother with this option. If you do care, or are sending naked RADIUS across the Internet without RADSEC, you may want to consider using it.
Now, whether or not you use this option you should NEVER use the anonymous identity for any sort of identification, policy decision,
or purpose with one exception: you can use the part after the '@' sign it to route a non-home realm user in a federation like eduroam to
his home AAA server so that you can ask that AAA server if his username and password is valid and if he should be allowed access
to your network based on an agreement between you and that other organzation.
Say for example, you had a rule saying any user named "bob" was allowed to log into a server. Anyone can put "bob" in the
anonymous identity instead of "anon." So never listen to what is in the anonymous identity. Make all your user-based policy decisions using only usernames from inside the encrypted tunnel. Likewise, if you controllers use the anonymous identity to display users in
the UI, this person will show up when you search for bob, even if their real username is nancy.
For this reason a lot of RADIUS servers will take the username from inside the encrypted tunnel and send it back to the controllers in the last RADIUS packet. When using PEAP, the last RADIUS packet is simply eaten by the NAS, so this is safe to do if your RADIUS
communications are secure -- it is never copied over into an EAPOL frame and sent over the air.
Rule #3: if you do not send inner identities back to your NAS, you probably do not want to use this option, because all your users in the contoller UI would be named "anon@realm.com" However, you should be aware that anyone that can perform a dot1x auth can fool your NAS into displaying whatever they want as their username. You probably do not want that to happen and might want to rethink your design.
Now just as a side-note, let's look back at the federated authentication (where you route to another organization's AAA server). If you do this, you have to rely on that AAA server to give you some sort of meaningful identifier for the user (preferred way is called a CUI, chargeable user identity) and this will be returned in at least the last RADIUS packet, if that insitution has set things up correctly. Since the client talks encrypted with their home server, you have no idea what their username is. Some home servers may send you back a meaningful outer username but you cannot rely on that either. You have to take the parts you have (CUI, the original realm you routed to, the MAC address, and home server's operator name from the home server's last packet) and do the best you can to display something useful in the NAS. You don't always have it, but prefrably you would want some digits of the CUID and the home realm to appear in your NAS, so you could file a complaint about misbehavior with the owner of the home server and they would know who's behavior you are complaining about, because they kept track of what CUIs they sent you for who.