Accepted Solutions
Probably a bug, see my note below.
The group is a container assigned to an agent, so when a userid comes in, and it is not found in the database or ldap, it looks in the group for aliases and tries to match with anyone, before outright denial. You can have one group for a thousand users, or a thousand groups, each for one user. And one user can have dozens of aliases...So, whatever way you want to do it is acceptable. Yes if you pick an alias that is the same as someone else alias, or duplicate of an actual userid, you can run into issues with that.
In this example, I have a user 'duff' who is in AD, and I made him a member of internal group 'many-aliases'
and you can see I have assigned a bunch to him (there are more hidden in the list)
Once I assign this group 'many-aliases' to an agent, user duff can login as duff or any other of these names
duff2,6,7,3 or others on that particular agent or agents only.
I can make someone else a member of 'many-aliases' and create another stack of aliases. Here pops is in two groups and has aliases in group aliasgrp as cfitz, and aliases in many-aliases also as pops2 and pops3. Pops can login on the agents that the groups are activated on, with the specific name pops or any valid alias.
NOTE: I did find a glitch in this. When creating aliases on this screen, the Radius Profile select box should say 'none' before you add more, or have a Radius Profile selected. It defaults to 'none'.
However, in some browsers, entering new aliases into the list may make the Radius Profile show blank instead of 'none'. When it is blank, it won't allow a new alias to be added. I have created a bugid for this. In the meantime, making sure 'none' is selected in the Radius Profile will allow you to add more aliases.
Probably a bug, see my note below.
The group is a container assigned to an agent, so when a userid comes in, and it is not found in the database or ldap, it looks in the group for aliases and tries to match with anyone, before outright denial. You can have one group for a thousand users, or a thousand groups, each for one user. And one user can have dozens of aliases...So, whatever way you want to do it is acceptable. Yes if you pick an alias that is the same as someone else alias, or duplicate of an actual userid, you can run into issues with that.
In this example, I have a user 'duff' who is in AD, and I made him a member of internal group 'many-aliases'
and you can see I have assigned a bunch to him (there are more hidden in the list)
Once I assign this group 'many-aliases' to an agent, user duff can login as duff or any other of these names
duff2,6,7,3 or others on that particular agent or agents only.
I can make someone else a member of 'many-aliases' and create another stack of aliases. Here pops is in two groups and has aliases in group aliasgrp as cfitz, and aliases in many-aliases also as pops2 and pops3. Pops can login on the agents that the groups are activated on, with the specific name pops or any valid alias.
NOTE: I did find a glitch in this. When creating aliases on this screen, the Radius Profile select box should say 'none' before you add more, or have a Radius Profile selected. It defaults to 'none'.
However, in some browsers, entering new aliases into the list may make the Radius Profile show blank instead of 'none'. When it is blank, it won't allow a new alias to be added. I have created a bugid for this. In the meantime, making sure 'none' is selected in the Radius Profile will allow you to add more aliases.
Even though this question is a few years old. I came across this when looking into the same issue so going to comment how I resolved the issue in case anyone comes across this themselves like I did working on the same problem and I was using the same document you did for reference.
So first you need to assign a token to a single user. Then you assign the aliases you want to use that account.
So obviously in the above picture, I've setup rsa.test1 to use a token and I'm telling it that rsa.test2 and rsa.test3 are aliases that are allowed to be used. So now we need to setup rsa.test2 and rsa.test3.
rsa.test1 is a member of the user groups g1 and g2.
rsa.test2 is a member of the user group g1.
rsa.test3 is a member of the user group g2.
In my current situation everyone is also a member of the rsa-challenges group as I was testing around with it.
rsa.test2 and rsa.test3 both say to only use the following aliases of rsa.test1. Both are able to work and authetnticate into my devices with the token holder, rsa.test1 because they are pointing to rsa.test1 in DIFFERENT groups.
If rsa.test2 was pointing to rsa.tes1 in the RSA-Challenges group, it would work, but if I try to add rsa.test3 to point to it as well. It would fail because rsa.test2 is already using that alias in that group.
Resulting in the error of "Found another user with the same alias in this group".
So as long as the test2 and test3 accounts are able to point to test1 in different groups, they'll be able to log into a device using rsa.test1 to authenticate them with the token.
Maybe there is a better way to work this stuff. This is what I found to be my problem and how I fixed it.
So to recap what anyone would need to do as I understand it, and if I get wording wrong anyone is welcome to correct that as I'm not by any means super efficient with RSA.
Whatever account is the token holder needs to be in the same user group as the alias that you want to use the token. If you are going to use more than 2 accounts with a token, then you will need the token holder to be in multiple groups and each alias needs to point to the token holder in a different group. If multiple aliases are trying to point to the token holder in the SAME group. It'll fail with the "Found another user with the same alias in this group'.
I know this is wordy. Hopefully people are able to understand what I'm saying and this helps somebody so they don't spend a few days working this out like I did.
