RSA integration problem: User TIME's access is denied

[LovasBalazs]

We're currently evaluation VDM and RSA. We have three VDM servers: two connection servers and one security server.

One of the CS is configured for plain AD authentication. It works just perfectly.

The other CS is linked with the SS and is configured for RSA. This VDM and the RSA AuthManager are on the same internal lan, the SS is in the DMZ.

We followed the manuals and probably have the RSA configured properly. However we're not able to login thru the SS with the RSA token.

When trying to come in from the internet we're promted for the RSA logon, supply the RSA userid with the passcode, yet we're access denied.

I'm totally clueless here...

The VDM events includes this strange event:

User TIME's access is denied

Any idea on this?

Thank you!

[mikefoley]

Hi,

Try the following:

On the Authentication Manager, run the Log Monitor utility. (Start...All Programs...RSA Security...RSA Authentication Manager Log Monitor)

Try logging in again to your VDM session. Report back what the error message is. That will help in debugging what is or isn't set up correctly.

Attached is the VMware/RSA implementation guide for setting up VDM and SecurID. Please use this to verify you have set everything up.

mike

RSA technical marketing

[LovasBalazs]

Dear Mike,

Thank you for your reply. I started Log Monitor and tried to logon to VDM with my token.

Interestingly the Log Monitor was empty, it didn't log any sort of authentation request at all. So I guess this shows that the VDM server might not forwad the authentication requests to the RSA at all?

Out of curiosity I recreated the Host Agent in RSA, and uploaded the file to the VDM server, but no change... (with or without checking the Clear Secret option)...

Indeed I followed the guide from RSA (BTW, there's a newer version out.)

I'm just out of ideas...

[LovasBalazs]

Oh, btw I just found that this error is also logged in VDM at the same time:

Cannot create RSA SecurID user authentication session net.propero.portal.filters.SecurIDAuthFilter3.f(SourceFile:869)

com.rsa.authagent.authapi.AuthAgentException: No Server available

[LovasBalazs]

Can believe this..

The RSA server sets the authentication service to Manual start thus the service was not running.

Once I started it everything went fine.

[mikefoley]

Argh.. That caught me once.

I'm glad it's working for you.

mike

[abbasi]

When you mention

The RSA server sets the authentication service to Manual start thus the service was not running.

Is that a setting on the RSA server?  If so where is it?  I am having the exact same issue with ver 4.5 and upgrading to 4.6 didn't help.  All the services on them View connection server appear to be running as they should

Also we are running RSA7.2 on an appliance

[markbenson]

>Is that a setting on the RSA server?

Yes. The setting is through Windows Service Control Manager on the RSA Authentication Manager server. Make sure the service is running and make sure it is not set to manual start so that it starts automatically at boot time.

To troubleshoot SecurID "Access denied" issues, go through the steps on page 135 here http://www.vmware.com/pdf/view-46-administration.pdf which covers Troubleshooting RSA SecurID Access Denial

Let us know what it was.

Mark.

[YotaMe]

I have the same trouble on View 4.6 connecting RSA AM.

I'm sure the service of RSA AM is working.

there are logs in VDM\logs as below.

20:51:39,675 WARN  <TP-Processor6> [AgentLogger]
(SESSION:A5B45BE75F2AF7BE9B5955A28357D045) User TIME's access is denied.
20:51:39,675 ERROR <TP-Processor6> [SecurIDAuthFilter3]
(SESSION:A5B45BE75F2AF7BE9B5955A28357D045) Cannot create RSA SecurID user
authentication session. Error was: No Server available
20:51:39,676 WARN  <TP-Processor6> [SecurIDAuthFilter3]
(SESSION:A5B45BE75F2AF7BE9B5955A28357D045) User crdnit has failed to
authenticate to VDM - reason: SecurID general error

Is anyone have some idea what should I check next?

[markbenson]

Keep checking the RSA Authentication Manager server and go through the referenced troubleshooting guide. View 4.6 works well with RSA SecurID auth so it's likely to be something wrong with your setup. Make sure the service is running. Make sure your RSA server is accessible. Look at the logs.

In your environment, has this ever worked? or are you setting this up for the first time?

When you get to the bottom of it, let us know what it was.

Thanks.

[abbasi]

I have the same issue and have had a support call open RSA now for 5 weeks (thier support is not very good) They have now accepted there is an issue and have finally escaled to second line support.  They actually refuse to support Win 2008  and will only support Connection servers that are Win 2003

Thier intial response was it is VMware's fault or our enviroment and would not even help out.  I didn't get further support from RSA till I escalated to our Account Manager at RSA

- The current use for the RSA is as a Radius for a Citrix Access Gateway which is functioning in production

- I did have a case open with VMware before contacting RSA and they verified the setup is correct (also confirmed because I can connect to Dev and Pre-Prod environments) and the only thing I can do on the VMware server side is select Clear Node Secret

- We had our Network Engineering do a trace on the traffic and they said the traffic is reaching the RSA.  I have done packet sniffing on my server and the attempts that fail always see 2 UDP packets leave and no response from RSA.  Successful attempts see two UDP Packets return from the RSA

- I verified the PIN+token is valid by a successful connection with the RSA Windows agent and to the Citrix

- All View servers are virtual machines with 1 nic and 1 static IP and no DNS alias

- All View servers are in the same AD domain and all were created from the same 2003 Template (only difference is IP address)

- All RSA use the same AD LDAP for user accounts

- Standard Agent is always used

- Same View Client is used in all tests

- In failed attempts there is no activity in the real-time authentication monitor

- I can load the sdconf.rec file for my Test and Pre-Pro enviroments and it works fine, as soon as I load the sdconf.rec for Production it doesn't work, so I know I have the View server config correct

- RSA and View servers can Ping each other

- The RSA server is a physical appliance and not a Windows machine or a VM

[markbenson]

As this setup works fine in so many other environments, I would check your configuration steps again. If you're not getting any reply from RSA Authentication Manager, it is likely that it is this that is not functioning correctly.

Look at the documentation on this starting on page 133 here - http://www.vmware.com/pdf/view-46-administration.pdf

Also look at this documentation http://www.rsa.com/rsasecured/guides/imp_pdfs/RSA%20SecurID%20Ready%20Implementation%20Guide-View%20... for steps on the setup needed for creating the "Authentication Agent record" and getting the sdconf.rec.

1. Check that the service is running on RSA Authentication Manager.

2. Check the logs on RSA Authentication Manager.

3. Create the agent record again on RSA Authentication Manager.

4. Export sdconf.rec and re-import it into View.

5. Clear node secret on View Connection Server and RSA Authentication Manager.

6. Check the logs again on RSA Authentication Manager.

If any of this is not setup correctly, View will report access denied in the View logs.

Support for View RSA SecurID authentication has worked in every version of View right back to the original VDM 2.0 through to the latest View 4.6. It doesn't matter if View Connection Server is running on Server 2003 or Server 2008.

The View implementation is verified by RSA for every major version in order to obtain the RSA Secured Solution accreditation andSecurID is used in a large number of production deployments including VMware's own production deployment.

Keep with it!. Let us know how you get on and when you've solved it, let us know what it was.

Thanks.

[YotaMe]

We have a View Manager 4.0 with RSA Secure-ID authentication and it works.

The problem occures when we configure a new View Manager of Ver 4.6, so there is no doubt that RSA AM works well.

The differences are Versions of View Manager and the locations of servers.

Both View Manager 4.0 and RSA AM are in a same segment. And View Manager 4.6 is in another segment.

But there are no firewall between these 2 segments and we allow to pass all TCP/UDP except broadcast.

Would you tell me what's "User TIME's access" means?

I think it may help us.

[abbasi]

"Users TIME Access" just means it has timed out

What we discovered is that in our enviroment we have 2 RSA appliances running as a Primary and a Replica.  The service on the primary had failed but the View Agent was not getting redirected to the Replica.  So it keep failing.  When we installed the RSA sdtest.exe

https://sftp.rsa.com/human.aspx?Username=support&password=Password1&arg01=656802971&arg12=downloaddi...

Unzip all files into your System32 (I have also attached the files if the link goes down)  Select do not replace if any of the files exist

Run the sdtest.exe while running a packet analyzer. and compare to what happens when you run the View client

For us when we ran the View Client we would see 2 UDP packets leave the View Connection Server for the Primary and no response and the client recieves and Access Denied Error.

When we run the sdtest.exe and look under Server Status it showed the primary server as 0.0.0.0 and it showed the replica as the correct address.  When we select Test Directly then the sdtest.exe gives a successful authentication and when looking at the packet trace it sends it's traffic directly to the replica.

So 2 things going on here.  First the RSA service was down.  Second the View client does not attempt to connect to the replica RSA file as defined in the sdconf.rec file

So I would request that VMware look at this issue as a possible bug fix.  This was tested on View 4.5 and 4.6

Message was edited by: abbasi

**NOTE**  If you make a successful connection from your View server to the RSA using the sdtest.exe or the RSA Windows agent you will have to go back and Clear the Node Secret on the View server as well as the RSA before attempting a View connection again.  The reason is that the sdtest.exe and the RSA Windows agent create a securid file that is not compatible with View and simply moving it into your System32 will not work.  The RSA tech explained that they have different formats of the securid file depending on which type of agent created it.  So you need to use one created by the View server

[markbenson]

abbasi, I don't think it is the same problem that YotaMe has, because in that case I think it is just a single RSA AuthMgr, but the information and detail you have provided is good information.

Yotame: make sure IP connectivity is possible between your new RSA AuthMgr and View Connection Server(s).

abbasi: Your saying that in your emvironment, RSA AuthMgr HA is not working in the case where one of your two AuthMgrs is down. I'll take a look at this because part of the certification testing includes specific tests for this, so in the certification environment this did work. I want to understand if this is a problem with the extracted sdconf.rec, or if there is a different reason. I'll progress this.

I'm sorry you're having trouble with this. SecurID works flawlessly in so many environments. We'll try and find out what's going on in this case.

Mark.

[YotaMe]

>make sure IP connectivity is possible between your new RSA AuthMgr and View Connection Server(s).

RSA AuthMgr is not new. It's already in our production use. We are adding a new View Connection Server.

As I said, we allow to pass all TCP/UDP except broadcast. It means some UDP of broadcast cannot pass the switch.

I can ping from the View Connection Server to RSA AuthMgr, and vice versa.

Could you tell me which port should we open for connections between RSA AuthMgr and View Connection Server?

[abbasi]

YotaMe - you need UDP 5500 open.

Doing a ping is ICMP and will only tell you that it is powered on and you don't need static routes to reach it

You cant try a Telnet on UDP 5500 to the RSA

Did you try the sdtest.exe utlity I uploaded?  It will tell you if your View server can connect on that port to the RSA

[abbasi]

Mark -

I agree it did work flawlessly and on the first try with both our test and pre-prod enviroments.  In our case the culprit was the services was down on the Primary but the View server was not attempting to connect to Replica servers

Our enviroment is now working, now that we have the service running on the Primary RSA.  Send me a email or a PM and I will give you more of the details on our configuration if you want to attempt to recreate it.  I did have a support case which is now closed if you would like me to reopen to feed the details through there

[YotaMe]

abbasi- I tested sdtest.exe and could connect to RSA AM.

So port 5500 is open. What's wrong then?

I'm setting a connection server on Windows 2008 R2.

There are both system32 and SysWOW64.

When I unzip all files of sdtest.exe in system32, it doesn't work, but it works in SysWOW64.

[abbasi]

YotaMe -

Do you have 1 RSA AM or multiple?

Do you have the ability to run a packet analyzer on both the View Server as well as the RSA AM at the same to monitor the traffic when a connection attempt is made?  Also watch the realtime Authentication Monitor on the RSA to see if a connection attempt is being made

Can you temporaily move the new Win2008 R2 connection server to the same subnet as the RSA AM and test View again, that will definatley rule out network issues.  Although if the sdtest was successful then your network should be good

Did you make sure the the View was created as a Standard Agent in RSA?

Are you running a firewall on the Win2008R2 server?  Double check it is not blocking traffic, also check who has rights on the System32 folder.  If the box is locked down you will have to temporarily give Everyone rigwrite/execute rights in Sys32.  Or set up a 2003 View server on the same subnet and try View 4.6 with that machine.  That will rule out if is a Windows version issue

*After connecting with the sdtest.exe make sure you go back and clear teh Node Secret from bothe the View and the RSA