SecurID^®

Hi, I need help locating the download for "rsa-am-vmware-virtualappliance-8.7.1.0.0.ova" per the instructions found in the RSA Authentication Manager 8.7 SP1 Setup and Configuration Guide. The download page only gives me the rsa-am-update-8.7.0.0.0, Thanks. ... View more

Article Number 000068206 Applies To Authentication Manager 8.x all versions Issue The RSA Authentication Manager Security Appliance is deployed with RSA self-signed Certificates, which are not signed by any of the Public Certificate Authorities, e.g. DigiCert, GoDaddy, Verisign, Komodo, etc... So default browsers report the AM appliance as Untursted. Image description Since all RSA customers download Authentication Manager software in a secure manner with RSA digital signatures, the Authentication Manager Appliance is a very secure web site, therefore Authentication Manager users should import the RSA self-signed Root CA cert to be trusted. To understand all of the implications why trusting the RSA self-signed Certificates have a look at Blog post from chief engineer/AM architect Piers Bowness on why replacement console certs does not make any sense with Authentication Manager https://community.rsa.com/t5/securid-community-blog/rsa-authentication-manager-and-self-signed-certificates/ba-p/519457 In certain circumstances it can be dangerous. I worked with a customer where the GPO policy was to block browser access to 'untrusted' web sites. This customer needed to revert to an RSA self-signed certificate for maintenance work, and locked themselves out of the RSA security console because of this policy. Authentication Manager is not a public commercial site, therefore the reason for publicly trusted certificates does not exist.It is at best a waste of money, at worst a potential S1 server down outage waiting to happen. Task 1.Export RSA self-signed Root CA with browser 2. Install RSA self-signed Authentication Manager Root CA certificate so that your browsers will trust it.     2.a. secpol.msc - Define Policy settings to Allow trusted root CA and peer trust certs     2.b. certmgr.msc - Trusted Root Cert Authorities - All Tasks - Import .crt/.cer file from step 1 Resolution 1.Export RSA self-signed Root CA with browser, by clicking into the Not Secure area of the URL in front of your AM primary Security Console URL https://<name>:7004/console-ims Image description From the drop-down select Certificate or Certificate is not Valid (Might need to select Under Connection is not secure to see something with 'Certificate' in it. Image description When the display for the Certificate(s) pops-up, there will be a [General] Tab with general information about the certificates, the primary cert as well as the RSA self-signed Root Certificate. Select the [Details] tab. Image description Highlight the Root Cert, which covers the primary and all current and future replicas. Then click the [Export] button at bottom right, and save as a .cer or .crt file, base-64 encoded (default). Note file name and location, e.g. RSA_root_CA_for_<server>.crt. 2. Install RSA self-signed Authentication Manager Root CA certificate so that your browsers will trust it.  First you need to allow your Security Settings to Allow trusted root CA and peer trust certs. This is done in Windows with the cmd secpol.msc, which you can type into the Windows search or at a CMD / Run prompt      2.a. secpol.msc - Define Policy settings to Allow trusted root CA and peer trust certs Image description Here you will Navigate to Public Key Policies - Certificate Path Validation Settings, and check off the   Define these policy settings   Allow trusted root CA to be used to validate certs    Allow peer trust certs       Click the [Apply] bottom right when these selections are made. Image description After these policy changes, you will need to import the RSA self-signed Root CA certificate that you exported in Step 1 above into Certificate Manager, certmgr.msc.  This is done in Windows with the cmd certmgr.msc, which you can type into the Windows search or at a CMD / Run prompt.  2.b. certmgr.msc - Trusted Root Cert Authorities - All Tasks - Import .crt/.cer file from step 1 Image description   Notes There are alternate ways to accomplish step 2, including using the MMC and CMD line certutil -addstore root <path>\<filename>.cer or .crt   ... View more

This guide is intended to provide instructions on how to configure vCloud Director as an SP (Service Provider) and RSA Via Access as an IdP (Identity Provider). Before we get started I will use these URLs throughout the guide: vCloud_Org_URL: https://VCLOUD_HOST/cloud/org/VCLOUD_ORGANIZATION/ for my internal testing it will be: https://myvcloud.com/cloud/org/via-saml/ RSA_Via_Portal_URL: https://portal.PDN for my internal testing it will be https://portal.singlepoint66.com Export vCloud Director Metadata If you would like you can also export the metadata from vCloud director. The URL for the metadata is the following: vCloud_ORG_URL/saml/metadata/alias/vcd in my case that's https://myvcloud.com/cloud/org/via-saml/saml/metadata/alias/vcd If you export the metadata you will get something like this: <?xml version="1.0" encoding="UTF-8"?> <md:EntityDescriptor entityID="https://myvcloud.com:443/cloud/org/via-saml/saml/metadata/alias/vcd" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">     <md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">         <md:KeyDescriptor use="signing">             <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">                 <ds:X509Data>                     <ds:X509Certificate>MIIB3T=</ds:X509Certificate>                 </ds:X509Data>             </ds:KeyInfo>         </md:KeyDescriptor>         <md:KeyDescriptor use="encryption">             <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">                 <ds:X509Data>                     <ds:X509Certificate>MIIB3TC=</ds:X509Certificate>                 </ds:X509Data>             </ds:KeyInfo>         </md:KeyDescriptor>         <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://myvcloud.com:443/cloud/org/via-saml/saml/SingleLogout/alias/vcd"/>              <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://myvcloud.com:443/cloud/org/via-saml/saml/SingleLogout/alias/vcd"/>                <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://myvcloud.com:443/cloud/org/via-saml/saml/SingleLogout/alias/vcd"/>               <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>          <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>              <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>             <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>           <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat>                  <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://myvcloud.com:443/cloud/org/via-saml/saml/SSO/alias/vcd" index="0" isDefault="true"/>                 <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser" Location="https://myvcloud.com:443/cloud/org/via-saml/saml/HoKSSO/alias/vcd" hoksso:ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" index="1" xmlns:hoksso="urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser"/>     </md:SPSSODescriptor> </md:EntityDescriptor>   If you import the metadata it will configure the connector to be Encrypt the Assertion and to validate the signed AuthN Request, but you can actually get without those.Here is how the import will look like:   Configure RSA Via Manually For vCloud Director The VMware site Enable Your Organization to Use an SAML Identity Provider has most of the requirements: Create an XML file with the following metadata from your SAML identity provider. The location of the single sign-on service The location of the single logout service The location of the service's X.509 certificate ..Configure your SAML provider to provide tokens with the following attribute mappings. email address = "EmailAddress" user name = "UserName" full name = "FullName" user's groups = "Groups" Let's start on the RSA SecurID side and create the connector, for the configuration we can use the following: Connection Flow: IDP-initiated Identity Provider URL: RSA_VIA_PORTAL_URL/IdPServlet?idp_id=vdirector_via in my case (https://portal.singlepoint66.com/IdPServlet?idp_id=vdirector_via) Issuer Entity ID: www.rsa.com ACS URL: vCloud_ORG_URL/saml/SSO/alias/vcd in my case ( https://myvcloud.com/cloud/org/via-saml/saml/SSO/alias/vcd ) I noticed in some cases it included the https port as seen in the Exported Metadata so in that case this was like this https://myvcloud.com:443/cloud/org/via-saml/saml/SSO/alias/vcd Audience Entity ID:  vCloud_ORG_URL/saml/metadata/alias/vcd in my case ( https://myvcloud.com/cloud/org/via-saml/saml/metadata/alias/vcd ) I noticed in some cases it included the https port as seen in the Exported Metadata so in that case this was like this https://myvcloud.com/cloud/org/via-saml/saml/metadata/alias/vcd NAME_ID Identifier Type: Subject or EmailAddress UserStore: AD Property: mail or sAMAccountName Include Certificate in Outgoing Assertion: Yes Sign Outgoing Assertion: Assertion within response Extended Attributes: Attribute Name User Store Property UserStore EmailAddress AD mail UserStore FullName AD cn UserStore UserName AD mail or sAMAccountName UserStore Groups AD virtualGroups Prepare SAML Metadata XML for vCloud Director   After the RSA SecurID application is created we can export the SAML metadata and modify it to be successfully imported into vCloud director. After the application is created you can go back to Application -> My Applications you can click on the drop down menu for the application and click Export Metadata:     By default the XML will look like this:   <?xml version="1.0" encoding="UTF-8"?> <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="vdirector_via">     <md:IDPSSODescriptor>         <md:KeyDescriptor use="signing">             <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">                 <ds:X509Data>                     <ds:X509Certificate>MIICsDCCA=</ds:X509Certificate>                 </ds:X509Data>             </ds:KeyInfo>         </md:KeyDescriptor>     <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>     <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>     <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>     <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://portal.singlepoint66.com/IdPServlet?idp_id=vdirector_via"/>     </md:IDPSSODescriptor> </md:EntityDescriptor> For the XML to be valid we need to add two sections the Logout_URL and the Attributes. For the Logout URL we just need to add the following into the XML: < SingleLogoutService Binding = "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location = "https://RSA_VIA_PORTAL_URL/LogoutServlet" /> In my case it was this: < SingleLogoutService Binding = "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location = "https://portal.singlepoint66.com/LogoutServlet" /> Adding the Attributes Entries into the SAML XML We have the list from above of what needs to be included in the XML. There is also a page from vCloud air that talks about these: Enabling and Managing Federation, from that page: Download the appropriate SAML metadata in XML format from your identity provider. The SAML metadata must provide mappings for the user attributes shown in this XML fragment: < saml:Attribute     FriendlyName = "Groups"     Name = "http://rsa.com/schemas/attr-names/2009/01/GroupIdentity"     NameFormat = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" /> < saml:Attribute     FriendlyName = "givenName"     Name = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"     NameFormat = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" /> < saml:Attribute     FriendlyName = "surname"     Name = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"     NameFormat = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" /> < saml:Attribute     FriendlyName = "Subject Type"     Name = "http://vmware.com/schemas/attr-names/2011/07/isSolution"     NameFormat = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" /> < saml:Attribute     FriendlyName = "userPrincipalName"     Name = "http://schemas.xmlsoap.org/claims/UPN"     NameFormat = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" /> < saml:Attribute     FriendlyName = "email"     Name = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"     NameFormat = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" /> So I ended up creating the following attributes in the XML: < Attribute Name = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" NameFormat = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName = "EmailAddress" xmlns = "urn:oasis:names:tc:SAML:2.0:assertion" /> < Attribute Name = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" NameFormat = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName = "FullName" xmlns = "urn:oasis:names:tc:SAML:2.0:assertion" /> < Attribute Name = "http://rsa.com/schemas/attr-names/2009/01/GroupIdentity" NameFormat = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName = "Groups" xmlns = "urn:oasis:names:tc:SAML:2.0:assertion" /> < Attribute Name = "http://schemas.xmlsoap.org/claims/UPN" NameFormat = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName = "UserName" xmlns = "urn:oasis:names:tc:SAML:2.0:assertion" /> In the end here is what I ended up with: <?xml version="1.0" encoding="UTF-8"?> <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="www.rsa.com">     <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">         <KeyDescriptor use="signing">             <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">                 <X509Data>                     <X509Certificate>MIICsDCCAZ=</X509Certificate>                 </X509Data>             </KeyInfo>        </KeyDescriptor>         <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"                              Location="https://portal.singlepoint66.com/LogoutServlet"/>         <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>         <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>         <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>         <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"                              Location="https://portal.singlepoint66.com/IdPServlet?idp_id=vdirector_via"/>         <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="EmailAddress" xmlns="urn:oasis:names:tc:SAML:2.0:assertion"/>         <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="FullName" xmlns="urn:oasis:names:tc:SAML:2.0:assertion"/>         <Attribute Name="http://rsa.com/schemas/attr-names/2009/01/GroupIdentity" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="Groups" xmlns="urn:oasis:names:tc:SAML:2.0:assertion"/>         <Attribute Name="http://schemas.xmlsoap.org/claims/UPN" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="UserName" xmlns="urn:oasis:names:tc:SAML:2.0:assertion"/>     </IDPSSODescriptor> </EntityDescriptor> NOTE: I also noticed that if the SSL certificates any New Line characters then vCloud Director doesn't like that. So make sure you remove any Carriage Returns from the SSL certificate in the XML. I also had to remove the md and ds prefixes on the XML entries. Enabling SAML SSO in vCloud Director   Now for the fun stuff. Login as a Organization Administrator into vCloud director and you will see the administration tab and the federation option within the administration tab:   Then check the Use SAML Identity Provider check box and either upload the file or just paste the XML (I just pasted it):     Upon hitting Apply it should accept the configuration. If the XML is mis-formed or missing any fields you will just get a generic message saying: The provided metadata is not a valid SAML 2.0 metadata document   Add SAML User to vCloud Director After the federation is enabled there will be a new option under Administration -> Users to import users: After you click import Users you can then enter a list of SAML users you want to add:   As you can see I just added one user called devuser. After it's imported you will see the user under the users section:     You can see the type for my test user is SAML. If you check out the properties of the user you will see they are empty: This is expected since the user hasn't logged into vCloud Director with RSA Via as the IdP. Since we configured the connector to send extended attributes those will be sent in the assertion when the user tries to login. Logging Directly to vCloud Director After Federation is Enabled You can still login as a local users. By default if you visit the vCloud_ORG_URL in my case: https://myvcloud.com/cloud/org/via-saml/ then you will be forwarded to the IdP. If you go to vCloud_ORG_URL/login.jsp (in my case https://myvcloud.com/cloud/org/via-saml/login.jsp) then you can still login as local users. ... View more

Hello, Currently on our Authentication agent setup, users only enter their username and RSA passcode (PIN + tokencode) to login to their windows machine. In testing the MFA agent deployment, it appears that we have to use windows password then RSA tokencode to login. Is there no way to prevent the windows password prompts without having to deploy physical security keys for passwordless setup? Why does the MFA agent not cache windows passwords like the authentication agent? With the Authentication agent support ending Sept 2022, this is going to be a huge impact to our organization. ... View more