ASA5520 - WebVPN authenticating to ACS, unable to lock users to specific groups/policies

Discussion in 'Cisco' started by mrolen@gmail.com, Aug 17, 2007.

  1. Guest

    Hello there,

    I have an ASA5520 with two WebVPN tunnel groups configured. One is
    very limited in the sites the users can access, the other is much more
    open and allows most of the features of WebVPN. Both tunnel groups
    are configured to authenticate users against ACS. I need to be able
    to lock users into the correct tunnel group based on their ACS
    credentials. The most ideal scenario would be to have this happen
    "behind the scenes", meaning I wouldn't have to enable the drop-down
    box on the WebVPN login page, which allows users to select the tunnel
    group manually; however, if the drop-down is required, I need the
    ASA5520 to be able to lock a user to a group, so that a user who is
    supposed to be in the limited group can not simply select the more
    open tunnel group in the drop-down list and authenticate, gaining more
    access than they are supposed to have (this is what happens
    currently... the ASA5520 completely ignores and and all tunnel-group
    information passed back to it from the ACS server).

    What I've been able to find in my searches indicates that I should be
    able to pass an IETF RADIUS attribute 25 back to the 5520 during
    authentication. This attribute supposedly just needs to contain
    "tunnel-group=WebVPN_Limited" in the case of my restricted WebVPN.
    Using debug on the 5520 shows that the attribute is indeed passed:


    --------------------------------------
    RADIUS packet decode (response)

    --------------------------------------
    Raw packet data (length = 85).....
    02 6d 00 55 b2 b9 f8 70 0b 1c 53 fd cf dd 62 48 | .m.U...p..S...bH
    93 f0 6a 05 19 1c 54 75 6e 6e 65 6c 2d 47 72 6f | ..j...Tunnel-Gro
    75 70 3d 4f 50 55 42 43 4f 57 45 42 56 50 4e 3b | up=OPUBCOWEBVPN;
    08 06 ff ff ff ff 19 1f 43 49 53 43 4f 41 43 53 | ........CISCOACS
    3a 30 30 30 34 62 66 61 31 2f 64 30 39 31 37 65 | :0004bfa1/d0917e
    31 35 2f 38 31 | 15/81

    Parsed packet data.....
    Radius: Code = 2 (0x02)
    Radius: Identifier = 109 (0x6D)
    Radius: Length = 85 (0x0055)
    Radius: Vector: B2B9F8700B1C53FDCFDD624893F06A05
    Radius: Type = 25 (0x19) Class
    Radius: Length = 28 (0x1C)
    Radius: Value (String) =
    54 75 6e 6e 65 6c 2d 47 72 6f 75 70 3d 4f 50 55 | Tunnel-Group=OPU
    42 43 4f 57 45 42 56 50 4e 3b | BCOWEBVPN;
    Radius: Type = 8 (0x08) Framed-IP-Address
    Radius: Length = 6 (0x06)
    Radius: Value (IP Address) = 255.255.255.255 (0xFFFFFFFF)
    Radius: Type = 25 (0x19) Class
    Radius: Length = 31 (0x1F)
    Radius: Value (String) =
    43 49 53 43 4f 41 43 53 3a 30 30 30 34 62 66 61 | CISCOACS:0004bfa
    31 2f 64 30 39 31 37 65 31 35 2f 38 31 | 1/d0917e15/81
    rad_procpkt: ACCEPT
    RADIUS_ACCESS_ACCEPT: normal termination
    RADIUS_DELETE
    remove_req 0xdccb720 session 0x94e id 109
    free_rip 0xdccb720
    radius: send queue empty

    --------------------------------------


    In the decode above, you see the "Tunnel-Group=OPUBCOWEBVPN;"
    attribute included in the response. However, the ASA5520 pays no
    attention at all. I was successfully logged into the less restricted
    WebVPN tunnel group using a test username that is configured to be
    locked down, simply by selecting the less restricted group from the
    drop-down list. Indeed, if the ASA5520 would accept the attributes
    being passed to it, this would be working as desired. If I change
    everything to LOCAL auth instead of using ACS, it all works
    perfectly. Unfortunately there are going to be hundreds of users, so
    the idea of doing local auth is out of the question.

    Does anyone know the magic setup to get the ASA5520 to behave as it is
    supposed to? Is attribute 25 (Class) not the right place to pass this
    tunnel group information back during authentication? Our local Cisco
    guy has replied to me indicating that attribute 25 is the right way to
    do it, to his knowledge. Unfortunately, it clearly doesn't work.
    Maybe the syntax is incorrect on the ACS server? I've entered the
    tunnel group info these four different ways:

    tunnel-group=OPUBCOWEBVPN
    tunnel-group=OPUBCOWEBVPN; <--- semicolon needed, maybe?
    Tunnel-Group=OPUBCOWEBVPN <-- "tunnel-group" is case sensitive,
    maybe?
    Tunnel-Group=OPUBCOWEBVPN; <-- case sensitive _and_ needs a
    semicolon, maybe?

    Any help is hugely appreciated,
    Mark
    , Aug 17, 2007
    #1
    1. Advertising

  2. Brian V Guest

    <> wrote in message
    news:...
    > Hello there,
    >
    > I have an ASA5520 with two WebVPN tunnel groups configured. One is
    > very limited in the sites the users can access, the other is much more
    > open and allows most of the features of WebVPN. Both tunnel groups
    > are configured to authenticate users against ACS. I need to be able
    > to lock users into the correct tunnel group based on their ACS
    > credentials. The most ideal scenario would be to have this happen
    > "behind the scenes", meaning I wouldn't have to enable the drop-down
    > box on the WebVPN login page, which allows users to select the tunnel
    > group manually; however, if the drop-down is required, I need the
    > ASA5520 to be able to lock a user to a group, so that a user who is
    > supposed to be in the limited group can not simply select the more
    > open tunnel group in the drop-down list and authenticate, gaining more
    > access than they are supposed to have (this is what happens
    > currently... the ASA5520 completely ignores and and all tunnel-group
    > information passed back to it from the ACS server).
    >
    > What I've been able to find in my searches indicates that I should be
    > able to pass an IETF RADIUS attribute 25 back to the 5520 during
    > authentication. This attribute supposedly just needs to contain
    > "tunnel-group=WebVPN_Limited" in the case of my restricted WebVPN.
    > Using debug on the 5520 shows that the attribute is indeed passed:
    >
    >
    > --------------------------------------
    > RADIUS packet decode (response)
    >
    > --------------------------------------
    > Raw packet data (length = 85).....
    > 02 6d 00 55 b2 b9 f8 70 0b 1c 53 fd cf dd 62 48 | .m.U...p..S...bH
    > 93 f0 6a 05 19 1c 54 75 6e 6e 65 6c 2d 47 72 6f | ..j...Tunnel-Gro
    > 75 70 3d 4f 50 55 42 43 4f 57 45 42 56 50 4e 3b | up=OPUBCOWEBVPN;
    > 08 06 ff ff ff ff 19 1f 43 49 53 43 4f 41 43 53 | ........CISCOACS
    > 3a 30 30 30 34 62 66 61 31 2f 64 30 39 31 37 65 | :0004bfa1/d0917e
    > 31 35 2f 38 31 | 15/81
    >
    > Parsed packet data.....
    > Radius: Code = 2 (0x02)
    > Radius: Identifier = 109 (0x6D)
    > Radius: Length = 85 (0x0055)
    > Radius: Vector: B2B9F8700B1C53FDCFDD624893F06A05
    > Radius: Type = 25 (0x19) Class
    > Radius: Length = 28 (0x1C)
    > Radius: Value (String) =
    > 54 75 6e 6e 65 6c 2d 47 72 6f 75 70 3d 4f 50 55 | Tunnel-Group=OPU
    > 42 43 4f 57 45 42 56 50 4e 3b | BCOWEBVPN;
    > Radius: Type = 8 (0x08) Framed-IP-Address
    > Radius: Length = 6 (0x06)
    > Radius: Value (IP Address) = 255.255.255.255 (0xFFFFFFFF)
    > Radius: Type = 25 (0x19) Class
    > Radius: Length = 31 (0x1F)
    > Radius: Value (String) =
    > 43 49 53 43 4f 41 43 53 3a 30 30 30 34 62 66 61 | CISCOACS:0004bfa
    > 31 2f 64 30 39 31 37 65 31 35 2f 38 31 | 1/d0917e15/81
    > rad_procpkt: ACCEPT
    > RADIUS_ACCESS_ACCEPT: normal termination
    > RADIUS_DELETE
    > remove_req 0xdccb720 session 0x94e id 109
    > free_rip 0xdccb720
    > radius: send queue empty
    >
    > --------------------------------------
    >
    >
    > In the decode above, you see the "Tunnel-Group=OPUBCOWEBVPN;"
    > attribute included in the response. However, the ASA5520 pays no
    > attention at all. I was successfully logged into the less restricted
    > WebVPN tunnel group using a test username that is configured to be
    > locked down, simply by selecting the less restricted group from the
    > drop-down list. Indeed, if the ASA5520 would accept the attributes
    > being passed to it, this would be working as desired. If I change
    > everything to LOCAL auth instead of using ACS, it all works
    > perfectly. Unfortunately there are going to be hundreds of users, so
    > the idea of doing local auth is out of the question.
    >
    > Does anyone know the magic setup to get the ASA5520 to behave as it is
    > supposed to? Is attribute 25 (Class) not the right place to pass this
    > tunnel group information back during authentication? Our local Cisco
    > guy has replied to me indicating that attribute 25 is the right way to
    > do it, to his knowledge. Unfortunately, it clearly doesn't work.
    > Maybe the syntax is incorrect on the ACS server? I've entered the
    > tunnel group info these four different ways:
    >
    > tunnel-group=OPUBCOWEBVPN
    > tunnel-group=OPUBCOWEBVPN; <--- semicolon needed, maybe?
    > Tunnel-Group=OPUBCOWEBVPN <-- "tunnel-group" is case sensitive,
    > maybe?
    > Tunnel-Group=OPUBCOWEBVPN; <-- case sensitive _and_ needs a
    > semicolon, maybe?
    >
    > Any help is hugely appreciated,
    > Mark
    >


    Not that this helps you with what you are looking for, but I could not get
    what you want to work and neither could Cisco. We litterally tried for over
    a month. What we ended up doing was pointing the groups to different
    authentication servers. We still had to use the drop down box, but if they
    selected the wrong one they didn't pass authentication.
    Brian V, Aug 17, 2007
    #2
    1. Advertising

  3. We recently set this up similar to what your describing.

    On the ASA
    We only define different tunnel groups for site to site (hardware VPN's).
    We used the default DefaultWEBVPNGroup for the tunnel group they would come
    in on and set the authentication to your Radius server. Next create a new
    group policy named GP-REMOTEGROUPA. Enable split tunneling so they "tunnel
    networks listed below". Next define your networks you will allow the client
    to access inside the network list.

    Inside AD create a group "GG-REMOTEGROUPA" and add any members you want to
    pull this policy.

    On to RADIUS - I am assuming your using IAS for RADIUS
    Create a new policy under "Remote Access Policies". Setup a custom policy
    "GG-REMOTEGROUPA". Inside Policy Conditions set your "Windows Group" to
    "GG-REMOTEGROUPA" (we defined that earlier inside AD). Grant access and
    click to "Edit Profile". Under "Authentication" tab untick everything but
    "Unencryped Access". Under "Encryption" tab untick everything but "No
    Encryption". Under "Advanced" tab remove everything and add back "Class"
    for the string value enter "OU=GP-REMOTEGROUPA". The OU part must match the
    group policy you setup on the ASA.

    That should do it. BTW we dont event display the drop down box at all.


    <> wrote in message
    news:...
    > Hello there,
    >
    > I have an ASA5520 with two WebVPN tunnel groups configured. One is
    > very limited in the sites the users can access, the other is much more
    > open and allows most of the features of WebVPN. Both tunnel groups
    > are configured to authenticate users against ACS. I need to be able
    > to lock users into the correct tunnel group based on their ACS
    > credentials. The most ideal scenario would be to have this happen
    > "behind the scenes", meaning I wouldn't have to enable the drop-down
    > box on the WebVPN login page, which allows users to select the tunnel
    > group manually; however, if the drop-down is required, I need the
    > ASA5520 to be able to lock a user to a group, so that a user who is
    > supposed to be in the limited group can not simply select the more
    > open tunnel group in the drop-down list and authenticate, gaining more
    > access than they are supposed to have (this is what happens
    > currently... the ASA5520 completely ignores and and all tunnel-group
    > information passed back to it from the ACS server).
    >
    > What I've been able to find in my searches indicates that I should be
    > able to pass an IETF RADIUS attribute 25 back to the 5520 during
    > authentication. This attribute supposedly just needs to contain
    > "tunnel-group=WebVPN_Limited" in the case of my restricted WebVPN.
    > Using debug on the 5520 shows that the attribute is indeed passed:
    >
    >
    > --------------------------------------
    > RADIUS packet decode (response)
    >
    > --------------------------------------
    > Raw packet data (length = 85).....
    > 02 6d 00 55 b2 b9 f8 70 0b 1c 53 fd cf dd 62 48 | .m.U...p..S...bH
    > 93 f0 6a 05 19 1c 54 75 6e 6e 65 6c 2d 47 72 6f | ..j...Tunnel-Gro
    > 75 70 3d 4f 50 55 42 43 4f 57 45 42 56 50 4e 3b | up=OPUBCOWEBVPN;
    > 08 06 ff ff ff ff 19 1f 43 49 53 43 4f 41 43 53 | ........CISCOACS
    > 3a 30 30 30 34 62 66 61 31 2f 64 30 39 31 37 65 | :0004bfa1/d0917e
    > 31 35 2f 38 31 | 15/81
    >
    > Parsed packet data.....
    > Radius: Code = 2 (0x02)
    > Radius: Identifier = 109 (0x6D)
    > Radius: Length = 85 (0x0055)
    > Radius: Vector: B2B9F8700B1C53FDCFDD624893F06A05
    > Radius: Type = 25 (0x19) Class
    > Radius: Length = 28 (0x1C)
    > Radius: Value (String) =
    > 54 75 6e 6e 65 6c 2d 47 72 6f 75 70 3d 4f 50 55 | Tunnel-Group=OPU
    > 42 43 4f 57 45 42 56 50 4e 3b | BCOWEBVPN;
    > Radius: Type = 8 (0x08) Framed-IP-Address
    > Radius: Length = 6 (0x06)
    > Radius: Value (IP Address) = 255.255.255.255 (0xFFFFFFFF)
    > Radius: Type = 25 (0x19) Class
    > Radius: Length = 31 (0x1F)
    > Radius: Value (String) =
    > 43 49 53 43 4f 41 43 53 3a 30 30 30 34 62 66 61 | CISCOACS:0004bfa
    > 31 2f 64 30 39 31 37 65 31 35 2f 38 31 | 1/d0917e15/81
    > rad_procpkt: ACCEPT
    > RADIUS_ACCESS_ACCEPT: normal termination
    > RADIUS_DELETE
    > remove_req 0xdccb720 session 0x94e id 109
    > free_rip 0xdccb720
    > radius: send queue empty
    >
    > --------------------------------------
    >
    >
    > In the decode above, you see the "Tunnel-Group=OPUBCOWEBVPN;"
    > attribute included in the response. However, the ASA5520 pays no
    > attention at all. I was successfully logged into the less restricted
    > WebVPN tunnel group using a test username that is configured to be
    > locked down, simply by selecting the less restricted group from the
    > drop-down list. Indeed, if the ASA5520 would accept the attributes
    > being passed to it, this would be working as desired. If I change
    > everything to LOCAL auth instead of using ACS, it all works
    > perfectly. Unfortunately there are going to be hundreds of users, so
    > the idea of doing local auth is out of the question.
    >
    > Does anyone know the magic setup to get the ASA5520 to behave as it is
    > supposed to? Is attribute 25 (Class) not the right place to pass this
    > tunnel group information back during authentication? Our local Cisco
    > guy has replied to me indicating that attribute 25 is the right way to
    > do it, to his knowledge. Unfortunately, it clearly doesn't work.
    > Maybe the syntax is incorrect on the ACS server? I've entered the
    > tunnel group info these four different ways:
    >
    > tunnel-group=OPUBCOWEBVPN
    > tunnel-group=OPUBCOWEBVPN; <--- semicolon needed, maybe?
    > Tunnel-Group=OPUBCOWEBVPN <-- "tunnel-group" is case sensitive,
    > maybe?
    > Tunnel-Group=OPUBCOWEBVPN; <-- case sensitive _and_ needs a
    > semicolon, maybe?
    >
    > Any help is hugely appreciated,
    > Mark
    >
    Its me Earnest T., Aug 18, 2007
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Raj
    Replies:
    0
    Views:
    875
  2. jmarkotic
    Replies:
    2
    Views:
    1,519
    jmarkotic
    Jan 8, 2004
  3. japper_uk
    Replies:
    1
    Views:
    538
    Walter Roberson
    Apr 27, 2004
  4. Replies:
    0
    Views:
    2,785
  5. Lost Pixel
    Replies:
    0
    Views:
    370
    Lost Pixel
    May 6, 2008
Loading...

Share This Page