On Sat, Jan 3, 2015 at 4:21 PM, Fromzy <fromzy at gmail.com> wrote: >> I'm really not that familiar with CSD, but isn't it possible that you've actually posted an *unacceptable* response to the CSD scan, causing all login attempts to fail? > > How to know ? But I think that if response is unacceptable, it simply > stops as it happens before with the "prelogin" failed message in > cstub.log Not all CSD failures will be visible from the client side. You could post an unacceptable response, then the gateway will still ask for your l/p and deny access. A CSD response that is unacceptable for some users might be considered acceptable for other users. e.g. the admins might have God Mode enabled on their accounts. If you know something about how your ASA is set up, you might be able to distinguish acceptable versus unacceptable responses from the cstub logs. I haven't tried to do this. > Or is that not how it works? I don't know > >> Are you really being asked for username and password *twice* in the same request? > > It asks one time, then it asks again because my credententials do not > work first time...I expect it > > I found a post between you and Kevin Cernekee in March 2013 where you > probably explain what happens to me : > http://t3182.network-vpn-openconnect-development.networktalks.us/errors-t3182.html > "- Some servers appear to be set up to reject clients that aren't > using XML POST (you'll get Login Denied even with a valid l/p). This > might be related to the use of hostscan/CSD, and the desire to use the > newer hostscan implementations which are tightly integrated into > AnyConnect." > > I have tried to launch openconnect with or without --no-xmlpost > parameter but nothing changes. In my case, the gateway was set up to allow access to CSD-passing Windows clients only. My results looked something like: - AnyConnect Windows: successful login - AnyConnect Linux: login denied with a custom error message - openconnect + no XML POST, identify as any OS: login denied. The result would look the same as a bad password (but it will probably log something different on the other side). - openconnect + XML POST, identify as Linux: login denied with a custom error message - openconnect + XML POST, identify as Windows: successful login There is also another case in which enabling XML POST prevents you from finding the "old" cstub binaries and forces you to set up a wrapper script. Haven't seen it personally but a few people on the list have run into it.
