User Guide for Cisco Digital Media Manager 5.4.x

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Book Contents
Find Matches in This Book
Available Languages
Download Options

Book Title

User Guide for Cisco Digital Media Manager 5.4.x

Chapter Title

08. Authentication and Federated Identity

Results

Updated:
May 4, 2015

Chapter: 08. Authentication and Federated Identity

Authentication and Federated Identity

Revised: May 4, 2015
OL-15762-05

 

 

 

Audience
 

We prepared this material with specific expectations of you.

Embedded Mode — You understand fundamental principles of user authentication.

LDAP Mode — you are a Microsoft Active Directory expert with real-world experience in its configuration and administration.

Federation Mode — you are a SAML 2.0 expert with real-world experience in its configuration and administration, including import and export of SAML 2.0-compliant IdP and SP configuration files.

Concepts

Overview

User authentication features of DMS-Admin help you to:

  • Authenticate all user sessions. ( We prevent you from disabling mandatory authentication, even though we allowed this in Cisco DMS 5.1.x and prior releases. )
  • Choose and configure an authentication method.
  • Import user account settings from an Active Directory server.
  • Synchronize user groups from an Active Directory server. Microsoft Active Directory is the only LDAP implementation that we support in this release.
  • Use federation services with a SAML 2.0-compliant IdP to support SP-initiated “single sign-on” login authentication in your network (following an initial synchronization to a Microsoft Active Directory Server that populates the DMM user database).

Note We support your use of one — and only one — IdP server with Cisco DMS 5.4.

Glossary

Timesaver Go to terms that start with... [ A | C | D | F | I | L | O | P | R | S | U | X ].

 

A
 
Active Directory
Microsoft implementation of LDAP. A central authentication server and user store. Active Directory is the only LDAP implementation that we support in this release.
Active Directory forest
A domain-straddling combination of Active Directory trees within an organization that operates multiple Internet domains. Thus, the forest at “Amalgamated Examples, LLC” might straddle all trees across example .com , example .net , and example .org .
Or, to use Cisco as a real-world case-study, one forest could straddle cisco.com and webex.com , among others.

Note This Cisco DMS release does not support Active Directory forests.
Active Directory tree
A subdomain-straddling combination of IdPs throughout one Internet domain. These IdPs operate collectively on behalf of the Internet domain’s constituent subdomains. Thus, the “tree” at example.com might encompass all of the IdPs to authenticate user sessions within subdomains such as these:
  • legal .example.com
  • sales .example.com
  • support .example.com
administrator DN
The DN to authenticate your Active Directory server’s administrator.

Note This release is more strict than most prior releases in its enforcement of proper LDAP syntax. Now, when you specify the administrator DN, you must use proper syntax, which conforms exactly to LDIF grammar.

  • Proper syntax: CN=admin1,OU=Administrators,DC=example,DC=com
  • Poor syntax: EXAMPLE\admin1

 

OTHERWISE

When you use poor syntax here for the first time while your DMM appliance runs DMS 5.3, we show you, the administrator, this error message: “Invalid username or password.”

But if you used and validated poor syntax here before upgrading to Cisco DMS 5.3, we do not repeat the validation process. Therefore — even though we do not show an error message to anyone — LDAP users simply cannot log in .

Note An LDAP expression must never include a space immediately to either side of a “=” sign. Similarly, it must never include a space immediately to either side of an “objectClass” attribute. Otherwise, validation fails.
authentication
The process to verify if a directory service entity has correctly claimed its own identity.

 

C
Glossary
CA
certification authority . Authority that issues and manages security credentials and public keys, which any directory service entity relies upon to encrypt and decrypt messages exchanged with any other directory service entity. As part of a public key infrastructure (PKI), a CA checks with a registration authority (RA) to verify information that certificate requestors provide. After the RA verifies requestor information, the CA can then issue a certificate.
CN
common name . An attribute-value pair that names one directory service entity but indicates nothing about its context or position in a hierarchy. For example, you might see cn=administrator . But cn=administrator is so commonplace in theory that it might possibly recur many times in an Active Directory forest, while referring to more than just one directory service entity. An absence of context means that you cannot know which device, site, realm, user group, or other entity type requires the implied “administration” or understand why such “administration” should occur.
Therefore, use of a standalone CN is limited in the LDIF grammar. Absent any context, a standalone CN is only ever useful as an RDN.

Note An LDAP expression must never include a space immediately to either side of a “=” sign. Similarly, it must never include a space immediately to either side of an “objectClass” attribute. Otherwise, validation fails.
CoT
circle of trust . The various SP that all authenticate against one IdP in common.

 

D
Glossary
DC
domain component . An attribute to designate one constituent part of a fully-qualified domain name (FQDN). Suppose for example that you manage a server whose FQDN is americas.example.com . In this case, you would link together three DC attribute-value pairs: DC=Americas,DC=example,dc=com.

Note An LDAP expression must never include a space immediately to either side of a “=” sign. Similarly, it must never include a space immediately to either side of an “objectClass” attribute. Otherwise, validation fails.
digital certificate
Uniquely encrypted digital representation of one directory service entity, whether physical or logical. This trustworthy representation certifies that the entity is not an imposter when it sends or receives data through a secured channel. The CA normally issues the certificate upon request by the entity or its representative. The requestor is then held accountable as the “certificate holder.” To establish and retain credibility, a certificate must conform to requirements set forth in International Organization for Standardization (ISO) standard X.509. Most commonly, a digital certificate includes the following.
  • One DN to authenticate the directory service entity.
  • One DN to authenticate the CA.
  • A serial number to identify the digital certificate itself.
  • An expiration date, after which any entity that receives the certificate should reject it.
  • A copy of the certificate holder’s public key.
  • The CA’s digital signature, so recipients can verify that the certificate is not forged.
directory service entity
Any single, named unit at any level within a nested hierarchy of named units, relative to a network. An entity’s essence depends upon its context. This context, in turn, depends upon interactions between at least two service providers — one apiece for the naming service and the directory service — in your network. Theoretically, an entity might represent any tangible thing or logical construct.
  • By “tangible thing,” we mean something that a person could touch, which occupies real space in the physical world. For example, this entity type might represent one distinct human being, device, or building.
  • By “logical construct,” we mean a useful abstraction whose existence is assumed or agreed upon but is not literally physical. For example, this entity type might represent one distinct language, subnet, protocol, time zone, or ACL.
An entity’s purpose is broad and flexible within the hierarchical context that defines it.
DN
distinguished name . A sequence of attributes that help a CA to distinguish a particular directory service entity uniquely for authentication. Distinct identity in this case arises from a text string of comma-delimited attribute-value pairs. Each attribute-value pair conveys one informational detail about the entity or its context. The comma-delimited string is the actual DN. It consists of the entity’s own CN, followed by at least one OU, and then concludes with at least one DC. For example:
CN=username,OU=California,OU=west,OU=sales,DC=Americas,DC=example,DC=com

Note An LDAP expression must never include a space immediately to either side of a “=” sign. Similarly, it must never include a space immediately to either side of an “objectClass” attribute. Otherwise, validation fails.

Thus, each DN represents more than merely one isolated element. A DN also associates the element to its specific context within the Active Directory user base that your IdP depends upon.
Glossary
federation
The whole collection of authentication servers that make SSO possible in a network by synchronizing their user bases to one IdP in common. This mutualized pooling of user bases bestows each valid user with a “federated identity” that spans an array of your SPs.

 

I
Glossary
IdP
identity provider . One SAML 2.0-compliant server (synchronized to at least one Active Directory user base), that authenticates user session requests upon demand for SPs in one network subdomain. Furthermore, an IdP normalizes data from a variety of directory servers (user stores).
Users send their login credentials to an IdP over HTTPS, so the IdP can authenticate them to whichever SPs they are authorized to use. As an example, consider how an organization could use three IdPs.
  • An IdP in legal .example.com might authenticate user sessions for one SP, by comparing user session requests to the user base records from one Active Directory server.
  • An IdP in sales .example.com might authenticate user sessions for 15 SPs, by comparing user session requests to the user base records from three Active Directory servers.
  • An IdP in support .example.com might authenticate user sessions for four SPs, by comparing user session requests to the user base records from two Active Directory servers.

 

Caution Only a well known CA can issue the digital certificate for your IdP. Otherwise, you cannot use SSL, HTTPS, or LDAPS in Federation mode and, thus, all user credentials are passed in the clear.
Glossary
LDAP
Lightweight Directory Access Protocol . A highly complex data model and communications protocol for user authentication. LDAP provides management and browser applications with access to directories whose data models and access protocols conform to X.500 series (ISO/IEC 9594) standards.

Note Microsoft Active Directory is the only LDAP implementation that we support in this release.
LDAPS
Secure LDAP . The same as ordinary LDAP, but protected under an added layer of SSL encryption.

Note Before you try to configure SSL encryption and before you let anyone log in with SSL, you MUST:
• Activate SSL on your Active Directory server and then export a copy of the server’s digital certificate.
• Import into DMM the SSL certificate that you exported from Active Directory.
• Restart Web Services (Tomcat) in AAI.

Caution Is your DMM appliance one half of a failover pair?
If so, you will trigger immediate failover when you submit the command in AAI to restart Web Services. This occurs by design, so there is no workaround.
LDIF
LDAP Data Interchange Format . A strict grammar that SPs and IdPs use to classify and designate named elements and levels in Active Directory.

 

O
Glossary
OpenAM
SAML 2.0-compliant identity and access management server platform written in Java. OpenAM is open source software available under the Common Development and Distribution (CDDL) license. OpenAM is derived from and replaces OpenSSO Enterprise, which also used CDDL licensing. See http://www.forgerock.com/openam.html .
OU
organizational unit . An LDIF classification type for a logical container within a hierarchical system. In LDIF grammar, the main function of an OU value is to distinguish among superficially identical CNs that might otherwise be conflated. For example:
• CN=John Doe,OU=sales,DN=example,DN=com
• CN=John Doe,OU=marketing,DN=example,DN=com
 

Note An LDAP expression must never include a space immediately to either side of a “=” sign. Similarly, it must never include a space immediately to either side of an “objectClass” attribute. Otherwise, validation fails.

 

P
Glossary
PingFederate
SAML 2.0-compliant identity and access management server platform written in Java. PingFederate is proprietary, commercial software. See http://www.pingidentity.com .

 

R
Glossary
RDN
relative distinguished name . The CN for a directory service entity, as used exclusively (and still without any explicit context) by the one IdP that has synchronized this entity against an Active Directory user base. When an IdP encounters any RDN attribute in an LDIF reference, the IdP expects implicitly that its SAML 2.0-synchronized federation is the only possible context for the CN. It expects this because an IdP cannot authenticate — and logically should never encounter — a directory service entity whose RDN is meaningful to any other federation.

 

S
Glossary
SAML
Security Assertion Markup Language . XML-based open standard that security domains use to exchange authentication and authorization data, including assertions and security tokens. We support SAML 2.0.
Shibboleth
A SAML 2.0-compliant architecture for federated identity-based authentication and authorization.
SP
service provider . Server that requests and receives information from an IdP. For example, your DMM server is an SP for Cisco DMS.
SSO
single sign on . (And sometimes “single sign off . ” ) The main user-facing benefit of federation mode is that SPs begin — and end, in some implementations — user sessions on behalf of their entire federation. SSO is a convenience for users, who can log in only once per day as their work takes them between multiple servers that are related but independent. Furthermore, SSO is a convenience to IT staff, who spend less time on user support, password fatigue, compliance audits, and so on.
  • We DO NOT support single sign off in Cisco DMS 5.3.
  • We support only SP-initiated SSO in Cisco DMS 5.3.

 

U
Glossary
user base
The location of the user subtree in the LDAP directory tree. For example, DC=ad,DC=com .

Note An LDAP expression must never include a space immediately to either side of a “=” sign. Similarly, it must never include a space immediately to either side of an “objectClass” attribute. Otherwise, validation fails.
user base DN
The DN for an Active Directory user base.

Note An LDAP expression must never include a space immediately to either side of a “=” sign. Similarly, it must never include a space immediately to either side of an “objectClass” attribute. Otherwise, validation fails.
user filter
A user filter limits the scope of an agreement to import filtered records from an Active Directory user base.

Note An LDAP expression must never include a space immediately to either side of a “=” sign. Similarly, it must never include a space immediately to either side of an “objectClass” attribute. Nor can a group name include any spaces. Otherwise, validation fails.

 

X
Glossary
X-509

A standard for public key infrastructure. X.509 specifies, among other things, standard formats for public key certificates and a certification path validation algorithm.

Understand the Requirement to Authenticate Users

Although Cisco DMS always authenticates users, we support three authentication methods.

  • Embedded authentication is completely native to Cisco DMS. It does not depend on any external servers.
  • LDAP authentication causes Cisco DMS products to rely on one — and only one — Microsoft Active Directory server and a Microsoft Internet Information Server (IIS). Thus, setup and operation with this method are more complex than with embedded authentication.
  • Federation mode — also known as single sign-on (SSO) causes Cisco DMS products to rely on a SAML 2.0-compliant IdP in combination with a Microsoft Active Directory server and IIS. Thus, setup and operation with this method are more complex than with LDAP authentication.

Note You must choose one of these methods. The method that you use determines which login screen your users will see.

Tip • After a user session times out, we prompt the affected user to log in twice.

  • Migration from one mode to another takes as long as 1 minute to finish (CSCtn22370).
  • An unresponsive Active Directory server can hang a login prompt for 20 minutes without any error message.

 

EMBEDDED MODE
LDAP MODE
FEDERATION (SSO) MODE 1

 

 

 

IdP-specific login screen

Related Topics

Decide Which Authentication Method to Use

 

LDAP and Active Directory Concepts

Note Microsoft Active Directory is the only LDAP implementation that we support in this release.

LDAP is Highly Complex

Caution LDAP-related features of Cisco DMS are meant for use by qualified and experienced administrators of Microsoft Active Directory. Unless you are an Active Directory and LDAP expert, we recommend that you use embedded authentication.

Plan Ahead

  • Install and configure Active Directory and Internet Information Services (IIS) before you try to configure LDAP authentication mode or federation mode in DMS-Admin.

Tip We support IIS 6 on Windows Server 2003.

  • Make sure that you have generated or imported certificates as necessary and activated SSL on the Active Directory server before you try to configure SSL encryption.

Restrictions

Cisco DMS Release
Support for Active Directory
Trees
Forests

5.3.0

Yes

No

Synchronization (Replication) Overview

Note Microsoft Active Directory is the only LDAP implementation that we support in this release.

When you choose LDAP authentication or SSO authentication, user account data originates from your Active Directory server. However, Cisco DMS does not synchronize (replicate) this data automatically, in real time. Instead, we cache it. Therefore, you must resynchronize user account data when you think it is appropriate to do so. You can:

  • Resynchronize manually.
  • Schedule synchronizations to recur in the future at set intervals.

DMS-Admin synchronizes all user accounts in the Active Directory “user base” that your filter specifies, except users whose accounts are disabled on your Active Directory server.

Synchronization Types

Note Microsoft Active Directory is the only LDAP implementation that we support in this release.

We support four types of Active Directory synchronization in LDAP mode or federation mode.

Initial
Update
Overwrite
Delete

Runs a one-time synchronization for a new filter that you never synchronized previously.

Runs an incremental, fast update to find and make up for any differences between user accounts that match your Active Directory filter and your local copy of those user accounts.

Overwrites your local copy of user accounts that correspond to your Active Directory filter with new copies of those user accounts. In addition, deletes your local copy of each user account that has been deleted from Active Directory since the last time that you ran a synchronization.

Deletes your local copy of user accounts that correspond to a defined Active Directory filter and deletes the entry for that filter from DMS-Admin.

 

Understand Synchronization of a DMM Group to an LDAP Filter

Note Microsoft Active Directory is the only LDAP implementation that we support in this release.

 

Is the Active Directory Filter Associated to a DMM User Group?
We Sync All Matching LDAP User Accounts to the
‘All Users’ Group in DMM
Associated User Group in DMM
Yes

Yes

Yes

No

Yes

N.A.
  • In most cases, you can associate one LDAP filter apiece to one DMM user group. Likewise, in most cases, you can associate one DMM user group apiece to one LDAP filter. The Digital Signs user group is an exception to both of these principles. It is built-in to Cisco DMS.
  • After you associate a DMM user group to an LDAP filter, you cannot use features on the Users tab to delete the DMM user group until after you delete the LDAP filter. However, even when you delete an LDAP filter, there is no requirement to delete its associated DMM user group. Furthermore, there is no way for you to delete the Digital Signs user group. It is built-in to Cisco DMS.

Understand Manual Synchronization

Note Microsoft Active Directory is the only LDAP implementation that we support in this release.

Manual synchronization mode requires you to choose Administration > Settings > Authentication > Synchronize Users > LDAP Bookmarks during all future synchronizations. Afterward, you must click Update.

Manual synchronization mode deletes your schedule for automatic synchronizations.

Understand Automatic Synchronization

Note Microsoft Active Directory is the only LDAP implementation that we support in this release.

Automatic synchronization mode automates and schedules incremental updates to user accounts that match Active Directory filters that you defined in DMS-Admin. When you use automatic synchronization mode, new fields and elements become available to you. These help you to configure the settings for automatic synchronization.

See the “Understand Synchronization of a DMM Group to an LDAP Filter” section .

Guidelines for Synchronization

Note Microsoft Active Directory is the only LDAP implementation that we support in this release.

We recommend that you synchronize your LDAP bookmarks periodically. Synchronization ensures that user and group membership associations are current and correct.

Sync Type
Best Practices
Initial

The Initial option is CPU-intensive for your DMM appliance and might lower performance temporarily. We recommend that you use it during off-peak hours only.

Update

We recommend that you use the Update option whenever:
Overwrite

Note The Overwrite option is CPU-intensive for your DMM appliance and might lower its performance temporarily. We recommend that you use this option during off-peak hours only.

  • After a user account is deleted from Active Directory, this option deletes the corresponding user account from DMM.
  • After a user account is associated to a new first name, last name, or username, this option overwrites the outdated user account attributes.
Delete
Caution The Delete option is destructive by design. We advise that you use it sparingly and with great caution.

Note Typically, the deletion process takes about 1 minute to finish. However, when there are more than 50,000 users in the Active Directory database, this process might run in the background and take about 30 minutes to finish. In this case, the user interface in DMS-Admin can show that a bookmark was deleted even though the actual process has not finished. If you observe this behavior, simply allow 30 minutes for the operation to finish.

Related Topics

Understand LDAP Attributes

Note Microsoft Active Directory is the only LDAP implementation that we support in this release.

Ordinarily, DMS-Admin will not import any user account record from your Active Directory server when the value in it is blank for any of these attributes:

  • Login User Name — This required value always must be unique.
  • First Name — This required value might be identical for multiple users.
  • Last Name — This required value might also be identical for multiple users.

However, you can import and synchronize all of the Active Directory user account records that match your filters. You can do this even when some of the user account records are incomplete because one or more of their attributes have blank values.

To prevent these undefined attributes from blocking the import of the user accounts they are meant to describe, you can enter generic values for most attributes in the Values to Use by Default column. DMS-Admin takes the generic values that you enter, and then inserts them automatically where they are needed.

Tip Nonetheless, you cannot enter a default value for the Login User Name attribute. Usernames are unique.

Guidelines for LDAP Filters

Note Microsoft Active Directory is the only LDAP implementation that we support in this release.

 

Use “OU” values to impose rough limits on a filter

  • Never use a filter that defines the user base at the domain level. For example, this filter is not acceptable.
DC=example,DC=com
 
  • Instead, use filters that define the user base at a lower level, as this one does.
OU=SanJose,DC=example,DC=com
 
  • LDAP returns matched records from all levels within the user base that your filter defines.
    • Would a filter for “ OU=SanJose,DC=example,DC=com ” ever include any users from...?

    OU=RTP,DC=example,DC=com

    No3

    OU=Milpitas,OU=SanJose,DC=example,DC=com

    Yes 4

    OU=Sunnyvale,OU=SanJose,DC=example,DC=com

    Yes 2

    3.Research Triangle Park, NC, does not have any physical connection to San José, CA.

    4.Milpitas, CA and Sunnyvale, CA, are suburbs of San José, CA, which affects them directly and in multiple ways.

Use “memberOf” values to pinpoint a filter more precisely

  • But what if you did not want to include any members of Milpitas or Sunnyvale? If your Active Directory server considered these cities (organizational units) to be subsets of San José, how could you exclude their members? To do so, you would use the
memberOf
 

attribute. It stops LDAP from matching records at any lower level than the one you name explicitly. In this scenario for example, you would use

memberOf=OU=SanJose,DC=example,DC=com
 

to match only the direct members of the “SanJose” OU.

Use “objectClass” values to match all user records

  • You can define a comprehensive filter that matches all user records.
objectClass=user

Understand the Effects of a Changed Password in Active Directory

Note Microsoft Active Directory is the only LDAP implementation that we support in this release.

After you change a user password on your Active Directory server, there is no requirement to resynchronize the affected user account in DMS-Admin.

Understand the Effects of a Blank Password in Active Directory

Note Microsoft Active Directory is the only LDAP implementation that we support in this release.

  • Even though it is possible in Active Directory to use a blank value for a password, Cisco DMS does not allow it.
  • When you choose LDAP authentication, any user whose Active Directory password is blank is prevented from logging in to any component of Cisco DMS.
  • Access is enabled or restored after the password is populated on the Active Directory server.

Understand Authentication Property Sheets for LDAP

Note Microsoft Active Directory is the only LDAP implementation that we support in this release.

The Authentication page contains four tabbed property sheets.

Select
Mode5

 

Embedded, LDAP or SSO

Select Mode is by default the only active tab. Your choices on the Select Mode property sheet determine whether you have access to the other three property sheets.

Define
Filter

 

LDAP or SSO

Your choices on the Define Filter property sheet help you to configure and add a new agreement.
Synchronize
Users

 

 

LDAP or SSO

Your choices on the Synchronize Users property sheet help you to submit a new agreement.
Manage
Attributes

 

 

LDAP or SSO

 

5.In most production environments, you can expect to use the Select Mode property sheet only one time.

IdP Requirements

To use federation (SSO) mode in Cisco DMS, you must have access to an IdP that meets our requirements. Your IdP must meet ALL OF THESE CRITERIA IN COMBINATION:

  • Support SAML 2.0.
  • Support these two SAML profiles:

– Web Browser SSO Profile

– Enhanced Client or Proxy (ECP) Profile

  • Generate assertions in which the SAML “UID” attribute is mapped to the local portion of an authenticated user’s username.
  • Generate SAML responses that are no larger than 16K bytes. (CSCua10799)
  • Use a digital certificate from a well-known CA (but only if you will use HTTPS).
  • Include a “<SingleSignOnService>” entry with SOAP binding in its IdP metadata. For example:

<SingleSignOnService Location=http://idp.example.com/idp/SSO.sml2” Binding=”urn:oasis:names:tc:SAML:2.0:bindings:SOAP”/>

 

In practice, these requirements limit your IdP to ones that we certify and NO OTHER. We certify OpenAM, PingFederate, and Shibboleth. (CSCua29696)

Configuration Workflow to Activate Federation (SSO) Mode

1. Configure and set up an Active Directory server.

2. Configure and set up a SAML 2.0-compliant IdP.

Note When you use a “fresh install” of Cisco DMS 5.3 (as opposed to an upgrade), your DMM appliance is configured to use embedded authentication mode by default. But when you upgrade a DMM server that was already configured for an earlier Cisco DMS release, it might use either embedded mode or LDAP mode.

3. Obtain a digital certificate from a trusted CA and install it on your IdP.

4. Use DMS-Admin to configure Cisco DMS for federation mode.

5. Export SAML 2.0-compliant metadata from your DMM server and import it into your IdP.

6. Export SAML 2.0-compliant metadata from your IdP and import it into your DMM server.

7. Configure Active Directory exactly as you would in LDAP mode.

8. Click Update to save your work, and then advance to the Synchronize Users property sheet.

9. Synchronize DMM with your Active Directory server to populate the DMM user database.

Note You MUST configure at least one LDAP bookmark.

10. Synchronize users exactly as you would in LDAP mode.

Note Whenever you change any setting or value on your IdP or any of your SPs, you must reestablish their pairing to restore mutual trust among them.

11. Click Update to save your work.

SSO Scenario 1 — Trusted + Valid + Authorized

1. A web browser requests access to a protected resource on an SP.

Your federation will not approve or deny this request until it knows more.

2. The SP asks its IdP if the browser is currently authenticated to any valid user account in the CoT.

3. The IdP verifies that:

  • The browser is already connected to an SP elsewhere in the CoT , having authenticated successfully to a valid user account and having received a SAML “token” or “passport” that authorizes at least some access.
  • The user account has sufficient permissions to access the protected resource.

4. The IdP acts on the SP’s behalf and redirects the browser immediately to the protected resource.

 

SSO Scenario 2 — Trusted + Valid + NOT Authorized

1. A web browser requests access to a protected resource on an SP.

Your federation will not approve or deny this request until it knows more.

2. The SP asks its IdP if the browser is currently authenticated to any valid user account in the CoT.

3. The IdP verifies that:

  • The browser is already connected to an SP elsewhere in the CoT , having authenticated successfully to a valid user account and having received a SAML “token” or “passport” that authorizes at least some access.
  • The user account DOES NOT have sufficient permissions.

4. The IdP redirects the browser to the SP , where an HTTP 403 Forbidden message states that the user is not authorized to access the protected resource.

 

SSO Scenario 3 — Nothing Known

1. A web browser requests access to a protected resource on an SP.

Your federation will not approve or deny this request until it knows more.

2. The SP asks its IdP if the browser is currently authenticated to any valid user account in the CoT.

3. The IdP reports that:

  • The browser is not yet connected to any SP in the CoT .
  • The browser is not yet authenticated to any valid user account.
  • We cannot tell if the browser’s human operator is a valid and authorized user, a valid but confused user, or an intruder.

4. The SP redirects the browser automatically to an HTTPS login prompt on the IdP, where one of the following occurs.

  • The browser’s human operator successfully logs in to a valid user account. The IdP attaches a SAML “token” or “passport” to the browser session, authorizing at least some access. And:

    – The user account has permission to access the protected resource. So, the IdP acts on
    the SP’s behalf and redirects the browser immediately to the protected resource.


OR
– The user account DOES NOT have permission to access the protected resource. So, the
IdP redirects the browser to the SP , where an HTTP 403 Forbidden message states that the user
is not authorized to access the protected resource.

  • The browser’s human operator fails to log in. So, lacking any proof that this person is authorized, we block access to every protected resource until the human operator can log in successfully.

 

Understand Migration (from Either LDAP or SSO) to Embedded

When you migrate from LDAP (via Active Directory) or federation mode to embedded authentication mode, you must explicitly choose whether to keep local copies of the:

  • User accounts that were associated to LDAP filters.
  • Groups and policies that were associated to LDAP filters.

Note • Unless you choose explicitly to keep the local copy of a user, a group, or a policy, we discard the local copy.

  • Migration from one mode to another takes as long as 1 minute to finish (CSCtn22370).

 

The result varies according to the combination of your choices.

When You Keep Local Copies of
The Result
Users
Groups
Policies

Yes

Yes

Yes

  • We preserve all local information.
  • We overwrite all LDAP-derived user account passwords with CiscoDMMvp99999 . 6

Yes

No

No
  • We preserve all local user accounts. However, we overwrite all LDAP-derived user account passwords with CiscoDMMvp99999 . 1
  • We discard all LDAP-derived groups.
  • We discard all LDAP-derived policies.

No

Yes

Yes

  • We discard all LDAP-derived user accounts.
  • We preserve all LDAP-derived groups. However, they are empty.
  • We preserve all LDAP-derived policies. Although they no longer apply to anyone, you can reuse them and apply them to any remaining user accounts and any future user accounts as you see fit.

No

No

No
  • We discard all LDAP-derived users, groups, and policies.

6.This security feature protects your network and user data. If anyone gains unauthorized access to the exported file and tries to use it, Active Directory rejects the invalid passwords.

Understand Migration (from Embedded) to Either LDAP or SSO

Note • Before you migrate from embedded authentication mode to federation mode, you must install a digital certificate from a trusted CA on your IdP server. Otherwise, you cannot migrate to federation mode at all.

  • After you migrate from embedded authentication mode to either LDAP (Active Directory) mode or federation mode, the locked property sheets become unlocked. You must use them.
  • Migration from one mode to another takes as long as 1 minute to finish (CSCtn22370).

 

Procedures

Export the Root CA X.509 Certificate from Your Active Directory Server

Procedure

Step 1 Open a web browser on your Active Directory server and connect to http://localhost/certsrv .

Step 2 Click Download a CA certificate .

Step 3 Choose the current CA certificate.

Step 4 Choose DER encoded .

The X.509 certificate that you export must be DER-encoded, and it can be binary or printable (Base64). However, when you use Base64, the certificate file must include these lines:

-----BEGIN CERTIFICATE-----
 
-----END CERTIFICATE-----
 

Step 5 Click Download CA certificate .

Step 6 Save this certificate in a file.

For example, you might call the certificate ADcertificate.cer .

Step 7 Stop. You have completed this procedure.

 

Configure DMM to Trust the Active Directory Root CA

Before You Begin

  • Log in to DMM.

Procedure

Step 1 Click Administration .

Step 2 Choose Security > Authentication > Select Mode .

Step 3 Choose LDAP .

Step 4 Check the Use SSL Encryption check box.

Additional user interface elements now appear, which are relevant to SSL and digital certificates.

Step 5 Upload the root CA certificate file that you saved locally.

a. Click Upload , and then click Add .

b. Browse to the file on a local volume.

c. Click the filename and press Enter .

d. Click OK to save your work and dismiss the dialog box.

Step 6 Enter the details for your Active Directory server.

Tip Be sure to use the logical port where your Active Directory server actually listens for SSL connections. The standard port number for LDAPS is 636. However, your Active Directory server might be configured to use some other port.

Step 7 As prompted, use DMS-Admin to restart Web Services (Tomcat).

The installed certificate cannot take effect until after you restart Tomcat.

Step 8 Stop. You have completed this procedure.

 

Choose an Authentication Method

Before You Begin

  • Log in to DMM.

Procedure

Step 1 Click Administration .

Step 2 Choose Security > Authentication .

Step 3 Use elements on the Select Mode property sheet to choose an authentication mode.

Step 4 Click Update .

Note Migration from one mode to another takes as long as 1 minute to finish (CSCtn22370).

The authentication settings that you changed are now in effect.

Step 5 Stop. You have completed this procedure.

 

What to Do Next

Related Topics

Define LDAP (Active Directory) Filters

Before You Begin

  • Log in to DMM.
  • Choose LDAP or federation as your authentication method.

Procedure

Step 1 Click Administration .

Step 2 Choose Security > Authentication .

Step 3 Click Define Filter .

Step 4 Do the following.

a. Use elements on the Define Filter property sheet to define, validate, and add one LDAP filter.

b. Click Update .

c. Repeat this step for each filter to be added.

The authentication settings that you changed are now in effect.

Step 5 Stop. You have completed this procedure.

 

Related Topics

Import User Accounts that Match an LDAP (Active Directory) Filter

Before You Begin

  • Log in to DMM.
  • Choose LDAP or SSO as your authentication method.
  • Define LDAP filters that will match the user accounts that you want to import.

Procedure

Step 1 Click Administration .

Step 2 Choose Security > Authentication > Synchronize Users.

Tip Is the Synchronize Users tab disabled (dimmed), so that you cannot click it? If so, refresh your browser.

Step 3 Find the relevant bookmark among all your saved bookmarks.

Step 4 Choose Initial as the synchronization type.

Step 5 Click Submit .

Note Please wait. Your request might take as long as 1 minute to process (CSCtn22370).

Step 6 Stop. You have completed this procedure.

 

What to Do Next

Related Topics

Resynchronize User Accounts that Match an LDAP (Active Directory) Filter

Before You Begin

  • Log in to DMM.
  • Choose LDAP or SSO as your authentication method.
  • Define LDAP filters.

Procedure

Step 1 Click Administration .

Step 2 Choose Security > Authentication > Synchronize Users.

Tip Is the Synchronize Users tab disabled (dimmed), so that you cannot click it? If so, refresh your browser.

Step 3 Find the relevant bookmark among all your saved bookmarks.

Step 4 Choose Update as the synchronization type.

Step 5 Click Submit .

Note Please wait. Your request might take as long as 1 minute to process (CSCtn22370).

Step 6 Stop. You have completed this procedure.

 

What to Do Next

Related Topics

Sever All Existing Ties to a User Base or an LDAP (Active Directory) Server

Before You Begin

  • Log in to DMM.
  • Choose LDAP or SSO as your authentication method.
  • Define LDAP filters.

Procedure

Step 1 Click Administration .

Step 2 Choose Security > Authentication > Synchronize Users.

Tip Is the Synchronize Users tab disabled (dimmed), so that you cannot click it? If so, refresh your browser.

Step 3 Click LDAP Bookmarks ,

Step 4 Delete all relevant filters from DMS-Admin.

Step 5 Click Update .

Note Please wait. Your request might take as long as 1 minute to process (CSCtn22370).

The authentication settings that you changed are now in effect.

Step 6 Stop. You have completed this procedure.

 

What to Do Next

Related Topics

Define the LDAP (Active Directory) Synchronization Schedule

Before You Begin

  • Log in to DMM.
  • Choose LDAP or SSO as your authentication method.
  • Define LDAP filters and bookmarks.

Procedure

Step 1 Click Administration .

Step 2 Choose Security > Synchronize Users > Scheduling ,

Step 3 Choose between manual synchronization and automatic synchronization.

Note You will not see any of the elements that the “Elements for Bookmarks” table describes until after you define at least one filter on the Define Filter property sheet.

Step 4 Click Update .

The authentication settings that you changed are now in effect.

Step 5 Stop. You have completed this procedure.

 

What to Do Next

Related Topics

Manage LDAP (Active Directory) Attributes

Before You Begin

  • Log in to DMM.
  • Choose LDAP or SSO as your authentication method.
  • Define LDAP filters and bookmarks.
  • Configure the LDAP synchronization schedule.

Procedure

Step 1 Click Administration .

Step 2 Click Security > Authentication > Manage Attributes .

Tip Is the Manage Attributes tab disabled (dimmed), so that you cannot click it? If so, refresh your browser.

Step 3 Use elements on the Manage Attributes property sheet to:

    • Set the associations between DMS-Admin attribute names and their corresponding Active Directory attribute names.
    • Use the predefined and typical names for Active Directory attributes (shown in grey text) or edit those attribute names so they match the names that your Active Directory server uses.
    • Enter the values to use by default in DMS-Admin when a user account attribute is not defined on your Active Directory server.

You must enter a value for each mandatory attribute. You cannot enter a value to use by default for user names, because each user name is unique.

Step 4 Click Update .

The authentication settings that you changed are now in effect.

Step 5 Stop. You have completed this procedure.

 

Related Topics

Configure Automatic LDAP (Active Directory) Synchronization

Before You Begin

  • Log in to DMM.
  • Choose LDAP or SSO as your authentication method.
  • Define LDAP filters and bookmarks.
  • Configure the LDAP synchronization schedule.

Procedure

Step 1 Click Administration .

Step 2 Choose Security > Authentication > Synchronize Users > Scheduling .

Step 3 Click the calendar icon ( ) to choose the start date for synchronization.

Step 4 Choose the hour and minute when synchronization should begin. Then, choose either AM or PM as the period.

Step 5 From the Repeat Interval list, choose the interval of recurrence:

Interval
Description

Never

Synchronization occurs once and does not recur.

Every Day

Synchronization recurs once every 24 hours. You must set the hour and minute when it should start.

Every Week

Synchronization recurs once every 7 days. You must set the hour and minute when it should start.

Every Month

Synchronization recurs once each month. You must set the hour and minute when it should start.

Custom

Synchronization recurs at an interval of your choosing. You must set the hour and minute when it should start.

Choose Days , Weeks , or Months as the interval type.

  • Choose a day of the month from 1 to 30 when the interval type is Days.
  • Choose a day of the week when the interval type is Weeks.
  • Choose an interval of recurrence from 1 to 6 when the interval type is Months.

Step 6 ( Optional )

    • Did you click the Automatic Synchronization radio button?
    • And should a one-time synchronization start immediately, in addition to the start date and time that you specified?

If so, check the Synchronize users immediately check box.

Step 7 Click Update .

The authentication settings that you changed are now in effect.

Step 8 Stop. You have completed this procedure.

 

Derive User Group Membership Dynamically from an LDAP (Active Directory) Filter

You can populate a user group with the returned output from a User Base DN query. However, a group of this kind differs in important ways from a group that you populate manually.

Note • Membership of such groups is dynamic — based on shared characteristics among the group of Active Directory users who match your query.

  • We update and clean these groups automatically during synchronization. Their membership will change after synchronization runs, when the corresponding records in Active Directory show that a user's membership should start or stop.
  • An imported Active Directory group is always read-only in DMS-Admin. By protecting it, we ensure that it is always correct, relative to the original and subject to any delay between synchronizations. For this reason, you cannot edit their memberships rolls manually.
  • When you try to delete a user from a group of this type, DMS-Admin shows an error message: “You cannot remove any user from a group associated with an LDAP bookmark.”

 

Before You Begin

  • Log in to DMM.
  • Choose LDAP as your authentication method.

Procedure

Step 1 Click Administration .

Step 2 Choose Security > Authentication > Define Filter.

Tip Is the Define Filter tab disabled (dimmed), so that you cannot click it? If so, refresh your browser.

Step 3 Use elements on the Define Filter property sheet to define, validate, and add one LDAP filter.

Step 4 Would you like to add users to a group that exists already? If so, choose that group name from the User Group (in DMM) list.

OR
Would you like to create and populate an entirely new group? If so, choose Create a New User Group from the User Group (in DMM) list. Then, give the new user group a name.

    • Group names in DMM can include alphanumeric characters ( 0–9 ; a–z ; A-Z ), hyphens ( - ), underscores ( _ ), and periods ( . ).
    • Spaces are forbidden.
    • Other forbidden characters include:
~‘!@#$%^&*()+={[}]|\:;”"’'<>?/
 

Step 5 Click Validate .

Step 6 Click Add .

Note Please wait. Your request might take as long as 1 minute to process (CSCtn22370).

Step 7 Stop. You have completed this procedure.

 

IdP Configuration Examples

This section includes configuration examples from IdP implementations that have passed internal Cisco tests for interoperability with Cisco DMS.

Note • We provide these rough examples as a courtesy only. We do not endorse any IdP by name, including any whose setup we mention by name in these examples. Likewise, we do not influence the development of any IdP. We do not know when or how its configuration workflows, daily operation, or overall quality might change in the future. For these reasons, we cannot know beforehand when or how the natural course of its ongoing development might invalidate one or more of the examples in this section. Therefore: Obtain all necessary IdP documentation from your IdP vendor, not Cisco.

  • You are free to choose, configure, and use an IdP at your own discretion — and your own risk. We do not develop, maintain, or support any IdP. Nor do we warrant that your choice of IdP is free of defects, non-infringing, or fit for any purpose.

 

Example: Configure OpenAM to Interoperate with Cisco DMS

Before You Begin

  • Obtain a digital identity certificate from a well-known CA, install it on your IdP host system, and then enable SSL.

Procedure

 

Step 1

Configure OpenAM to use a datastore from Active Directory, unless it already does so.

Note In Federation mode, we use a synchronization process to learn which usernames are valid in your organization. Later and separately, we use an authentication process to verify user-login credentials. And even though we expect most IdPs will source both of these services from a Microsoft Active Directory server, your organization might use some other other LDAP system to authenticate user sessions. When this is the case, you must install and configure an Active Directory server for synchronization use by Cisco DMS. Otherwise, we cannot learn which usernames are valid. In turn, ordinary users cannot log in to Cisco DMS. To prevent this outcome, you must replicate and synchronize a datastore between your new Active Directory server and your existing LDAP server. Afterward, Cisco DMS can synchronize with the Active Directory datastore.

a. In OpenAM Web, choose Access Control > Top Level Realm > Data Stores .

b. Enter values to define the attributes of your Active Directory DataStore.

You might enter values for some of the attributes (like these ones, for example)...

LDAP Server: < IP_ADDRESS >:389
 LDAP Bind DN: CN=Administrator,CN=Users,DC=win2003esx,DC=example,DC=com
 LDAP Bind Password: *********
 LDAP Organization DN: OU=SystemTest,DC=win2003esx,DC=example,DC=com
 LDAP Users Search Attribute: sAMAccountName
 LDAP Users Search Filter: (objectclass=user)
 Authentication Naming Attribute: sAMAccountName

... while leaving other attribute values undefined.

Attribute Name Mapping: < Empty >
 LDAP Groups Search Attribute: < Empty >
 LDAP Groups Search Filter: < Empty >
 LDAP Groups container Naming Attribute: < Empty >
 LDAP Groups Container Value: < Empty >
 Attribute Name of Unqiue Member: < Empty >
 LDAP People Container Naming Attribute: < Empty >
 LDAP People Container Value: < Empty >
 Persistent Search Base DN: < Empty >
 Persistent Search Filter: < Empty >

Note These are merely examples.

c. Click Federation , and then click your IdP server instance — for example, dmsIdp .

d. Click Assertion Processing .

e. Change the IDP Attribute Map value from UID=uid to UID=sAMAccountName .

Step 2

Install Enhanced Client or Proxy (ECP), a SAML profile plugin, if you will make API system calls to OpenAM7.

a. Log in to your Cisco.com user account.

b. Go to http://cisco.com/cisco/software/release.html?mdfid=280171249&softwareid=
282100271&release=5.3&rellifecycle=&relind=AVAILABLE&reltype=all , navigate to the download page for our implementation of ECP8, and then download it.

c. Use Maven or another method to download release 1.2.14 of the open source logging framework called log4j .

d. Copy your downloaded ECP and log4j files to /$OPENSSO_HOME/WEB-INF/lib , .

e. Restart your servlet container — for example, tomcat.

f. In OpenAM Web, click Federation , and then click your IdP server instance — for example, dmsIdp .

g. Click Advanced .

h. In the ECP Configuration area, set the IDP Session Mapper value to com.cisco.dms.core.security.aaa.sso.saml2.ecp.idp.plugin.DmsIDPECPSessionMapper .

i. Click Save .

Step 3

Export SP metadata from Cisco DMS.

Export metadata from each SP that will participate in your OpenAM CoT.

Tip For Cisco DMS, see the “Export SP Metadata from DMM” topic.

Step 4

Import SP metadata from Cisco DMS.

a. Go to the console page and click Register Remote Service Provider .

b. Check the File check box.

c. Click Upload , and then navigate to the SP metadata that you exported from DMS-Admin and saved as dms_sp_config.xml .

d. Click Configure , and then click Federation .

e. Make sure that dmsServiceProvider (SAMLv2 SP Remote) has a defined value.

Step 5

Make sure that OpenAM is configured to issue the Principal attribute.

a. In OpenAM Web, click Federation , and then click your IdP server instance — for example, dmsIdp .

b. Click Assertion Processing .

c. In the Attribute Mapper area, set the Attribute Map value to UID=uid .

d. Click Back .

e. Click the SP entity instance for your DMM appliance.

The Assertion Content tab is selected automatically.

f. In the Request/Response Signing area, check both of these check boxes:

  • Authentication Requests Signed
  • Assertions Signed

g. Choose Access Control > / (Top Level Realm) > Authentication .

h. Click All Core Settings .

i. Make sure that the User Profile value is set to Required .

This will cause OpenAM to pass the user IDs of logged-in users to DMM and your other SPs.

j. Click Save , and then click Back to Authentication .

k. Log out of OpenAM Web.

Step 6

Cause Cisco DMS to trust OpenAM.

See the “Import IdP Metadata into DMM” topic.

Step 7

Use the Linux CLI to export IdP metadata.

wget --no-check-certificate https:// <IdP_serverip> : <service_port> /opensso/saml2/jsp/exportmetadata.jsp -O dms_idp_config.xml

Step 8

Stop.

You have completed this procedure.

7.Also, DMS-Admin includes a feature to test the configuration of your IdP. In the case of OpenAM, this testing feature uses ECP and fails in its absence.

8.We provide a downloadable ECP implementation as a courtesy to you. Alternatively, you can obtain ECP from another source at your discretion.

Example: Configure Shibboleth to Interoperate with Cisco DMS

Before You Begin

  • Obtain a digital identity certificate from a well-known CA, install it on your IdP host system, and then enable SSL.

Procedure

 

Step 1

Obtain and install Shibboleth.

a. Go to http://www.shibboleth.net/downloads/identity-provider/latest/ .

b. Download the latest Identity Provider software package, such as shibboleth-identityprovider-2.3.0-bin.zip .

c. Extract the downloaded archive, and then make the installer script within it, named install.sh , executable. For example:

$ unzip shibboleth-identityprovider-2.3.0-bin.zip
$ cd shibboleth-identityprovider-2.3.0
$ chmod u+x install.sh

d. Run the script to install Shibboleth.

$ ./install.sh

  • The installer will prompt you to specify the installation directory. Its default is /opt/shibboleth-idp .
  • In addition, it will prompt you to enter your Shibboleth system’s FQDN, such as shibboleth.example.com .

Respond appropriately to these prompts.

Shibboleth is now installed and you have completed its basic configuration. Your new Shibboleth system contains these subfolders.

/opt/shibboleth-idp/ bin/
 /opt/shibboleth-idp/ conf/
 /opt/shibboleth-idp/ credentials/
 /opt/shibboleth-idp/ lib/
 /opt/shibboleth-idp/ logs/
 /opt/shibboleth-idp/ metadata/
 /opt/shibboleth-idp/ war/

 

Step 2

Export SP metadata from Cisco DMS.

Export metadata from each SP that will participate in your Shibboleth CoT.

Tip For Cisco DMS, see the “Export SP Metadata from DMM” topic.

Step 3

Import SP metadata from Cisco DMS.

Use SFTP or another method to save imported metadata where Shibboleth will access it: /opt/shibboleth-idp/metadata/ .

Step 4

Log in remotely.

Use SSH, remote desktop, VNC, or a direct console connection to log in remotely to the system where you installed Shibboleth.

Step 5

Edit the attribute filter file.

a. Open /opt/shibboleth-idp/conf/attribute-filter.xml for editing.

b. Change the attributeID value (at or near line 24) to uid .

<afp:AttributeRule attributeID="uid">
 

Step 6

Edit the attribute resolver file.

a. Open /opt/shibboleth-idp/conf/attribute-resolver.xml for editing.

b. Find this section:

<!- ========================================== ->
<!- Attribute Definitions ->
<!- ========================================== ->

 

c. Enter these lines after the Attribute Definitions section heading, at or near line 29.

<resolver:AttributeDefinition xsi:type="ad:Simple" id="uid" sourceAttributeID="sAMAccountName">
<resolver:Dependency ref="myLDAP" />
<resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.1" friendlyName="uid" />
<resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
</resolver:AttributeDefinition>
 

d. Find this section:

<!- ========================================== ->
<!- Data Connectors ->
<!- ========================================== ->

 

e. Enter these lines after the Data Connectors section heading, at or near line 288.

<resolver:DataConnector id="myLDAP" xsi:type="dc:LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
ldapURL="ldap:// < YOUR_ACTIVE_DIRECTORY_SERVER_IP > "
baseDN="cn= < USERBASE > , dc= < HOSTNAME > , dc= < EXAMPLE > , dc= < COM > "
principal="cn= < ADMINISTRATOR_CN > , cn= < USERBASE > , dc= < HOSTNAME > , dc= < EXAMPLE > , dc= < COM > "
principalCredential=" < ADMINISTTRATOR_PASSWORD > ">
<dc:FilterTemplate>
<![CDATA[
(sAMAccountName=$requestContext.principalName)
]]>
</dc:FilterTemplate>
<LDAPProperty name="java.naming.referral" value="follow"/>
</resolver:DataConnector>

Step 7

Edit the handler file.

a. Open /opt/shibboleth-idp/conf/handler.xml for editing.

b. Uncomment line 109.

<!-- Username/password login handler -->
<ph:LoginHandler xsi:type="ph:UsernamePassword"
jaasConfigurationLocation="file:///opt/shibboleth-idp/conf/login.config">
<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</ph:AuthenticationMethod>
</ph:LoginHandler>

Step 8

Edit the login config file.

a. Open /opt/shibboleth-idp/conf/login.config for editing.

b. Find this string, at or near line 45:

};
 

c. Enter this material immediately before }; .

edu.vt.middleware.ldap.jaas.LdapLoginModule optional
ldapUrl="ldap:// < YOUR_ACTIVE_DIRECTORY_SERVER_IP > :389"
bindDn="cn= < ADMINISTRATOR_CN > , cn= < USERBASE > , dc= < HOSTNAME > , dc= < EXAMPLE > , dc= < COM > "
bindCredential=" < ADMINISTTRATOR_PASSWORD > "
baseDn="cn= < USERBASE > , dc= < HOSTNAME > , dc= < EXAMPLE > , dc= < COM > "
ssl="false"
tls="false"
userFilter="sAMAccountName={0}";

Step 9

Edit the replying party file.

a. Open /opt/shibboleth-idp/conf/replying-party.xml for editing.

b. Find this section:

<!-- ========================================== -->
<!- Metadata Configuration ->
<!-- ========================================== -->
 

c. Enter these lines after the Metadata Configuration section heading, at or near line 123.

<metadata:MetadataProvider
id=" <HOSTNAME_ONLY_FOR_YOUR_SP> "
xsi:type="FilesystemMetadataProvider"
xmlns="urn:mace:shibboleth:2.0:metadata"
metadataFile="/opt/shibboleth-idp/metadata/ <EXPORTED_SP_SETTINGS_FILENAME> .xml"
maintainExpiredMetadata="true"
/>
</metadata:MetadataProvider>

Step 10

Prepare your Shibboleth config for use by Cisco DMS.

a. Open /opt/shibboleth-idp/metadata/opt/shibboleth-idp/metadata/Idp-metadata.xml for editing.

b. Delete lines 9 through 11.

<Extensions>
<shibmd:Scope regexp="false"> < EXAMPLE > . < COM > </shibmd:Scope>
</Extensions>
 

c. Delete lines 67 through 69.

<Extensions>
<shibmd:Scope regexp="false"> < EXAMPLE > . < COM > </shibmd:Scope>
</Extensions>
 

d. Find this string:

</IDPSSODescriptor>
 

e. Enter this new binding immediately before </IDPSSODescriptor> .

<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
Location="https:// < YOUR_SHIBBOLETH_SERVER_FQDN > :8443/idp/profile/SAML2/SOAP/ECP" />
 

f. Append :8443 to the end of every FQDN in this file.

g. Save your edited copy of this file to your local system.

Be sure to use your Shibboleth hostname in the local filename. For example, you might name this local copy idp-shibboleth.xml .

Step 11

Cause Cisco DMS to trust Shibboleth.

See the “Import IdP Metadata into DMM” topic.

Step 12

Deploy Shibboleth.

cp /opt/shibboleth-idp/war/idp.war /usr/local/tomcat/webapps/

Step 13

Test your work.

a. Restart Tomcat.

b. Check for the “OK” message at http:// < hostname > :8080/idp/profile/Status .

Step 14

Stop.

You have completed this procedure.

Example: Configure PingFederate to Interoperate with Cisco DMS

Before You Begin

  • Install PingFederate and configure it with at least one Adapter instance to your authentication server, such as LDAP or OAM.

Procedure

 

Step 1

Export SP metadata from Cisco DMM.

Export metadata from each SP that will participate in your PingFederate CoT.

Tip For Cisco DMS, see the “Export SP Metadata from DMM” topic.

Step 2

Import SP metadata into PingFederate.

a. Log in to PingFederate as its administrator.

b. Find the SP Connections area in the My IdP Configuration column and click Create New .

c. Click Do not use a template for this connection on the Configuring SP Connection/Connection Template page, and then click Next .

d. Check the Browser SSO Profiles check box on the Configuring SP Connection/Connection Type page, choose SAML 2.0 from the Protocols list, and then click Next .

e. Check the Browser SSO check box, and then click Next .

f. Click Choose File on the Configuring SP Connection/Import Metadata page, and then navigate to the SP metadata that you exported from DMS-Admin as dms_sp_config.xml .

g. Click Open , and then click Next THREE TIMES.

Step 3

Configure SAML profile settings and IdP assertions.

a. Click Configure Browser SSO on the Configuring SP Connection/Browser SSO page.

b. Check the SP Initiated SSO check box on the Browser SSO/SAML Profiles page, and then click Next TWO TIMES.

c. Click Configure Assertion Creation on the Browser SSO/Assertion Creation page.

d. Click Transient on the Assertion Creation/Identity Mapping page, check the Include attributes in addition to the transient identifier check box, and then click Next .

e. Set these attribute-value relationships in the Extend the Contract area on the Assertion Creation/Attribute Contract page.

  • SAML_AUTHN_CTX
     urn:oasis:names:tc:SAML:2.0:attrname-format:uri
  • UID
     urn:oasis:names:tc:SAML:2.0:attrname-format:uri

f. Click Next .

g. Click Map New Adapter Instance on the Assertion Creation/IdP Adapter Mapping page.

h. Choose your appropriate authentication type and adapter instance from the next two pages.

i. Click Next .

The username attribute that you need next is probably part of the adapter contract. Therefore:

j. Click Use only the Adapter Contract values in the SAML assertion on the IdP Adapter Mapping/Assertion Mapping page, and then click Next .

k. On the IdP Adapter Mapping/Attribute Contract Fulfillment page:

  • Set the source to Text for the SAML_AUTHN_CTX attribute contract. Then, set its value to urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
  • Set the source to Adapter for the UID attribute contract. Then:

– Locate an adapter value, such as subject or userId , that maps to the username.

– Set the UID attribute contract value to match the adapter value that you just found.

l. Click Next > Done > Next > Done > Next .

Step 4

Configure protocol settings.

a. Click Configure Protocol Settings on the Browser SSO/Protocol Settings page.

b. Make sure that the default binding value is set to POST on the Protocol Settings/Assertion Consumer Service URL page, delete all other bindings, and then click Next .

c. Clear the Artifact check box on the Protocol Settings/Allowable SAML Bindings page, and then click Next .

d. Check these check boxes on the Protocol Settings/Signature Policy page, and then click Next .

  • Require AuthN requests to be signed when received via the POST or Redirect bindings.
  • Always sign the SAML Assertion.

e. Click None on the Protocol Settings/Encryption Policy page.

f. Click Next > Done > Next > Done > Next .

Step 5

Configure credentials and their digital signatures.

a. Click Configure Credentials on the SP Connection/Credentials page.

b. Click Configure on the Credentials/Back-Channel Authentication page.

c. Check the Use Digital Signatures to guarantee payload in Browser SSO profile check box on the Back-Channel Authentication/Inbound SOAP Authentication Type page, and then click Next .

d. Click Done on the Back-Channel Authentication/Summary page.

e. Choose the appropriate certificate on the Credentials/Digital Signature Settings page, check the Include the certificate in the signature <KeyInfo> Element check box, and then click Next .

f. Click Manage Signature Verification Settings... on the Credentials/Signature Verification Settings page.

g. Click Unanchored on the Signature Verification/Trust Model page, and then click Next .

h. Choose your DMM certificate (example: dmm.example.com ) from the Primary list on the Signature Verification/Signature Verification Certificate page, and then click Next .

Note DO NOT choose any secondary certificate.


OR

If the Primary list does not include your DMM certificate, do the following.

1. Click Manage Certificates on the Signature Verification/Signature Verification Certificate page.

2. Click Choose File on the Import Certificate/Import Certificate page, and then navigate to the X509 digital certificate file (*.cer) that you output from DMM.

Note Make sure that your certificate file includes the preamble and postscript that are mandatory for PEM-formatted certificates. The preamble and postscript look like this.

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

3. Click Open , and then click Next THREE TIMES.

4. Check the Make this the active certificate check box on the Import Certificate/Summary page, and then click Done .

 

i. Click Done on the Certificate Management/Manage Digital Verification Certificates page.

j. Click Next on the Signature Verification/Signature Verification Certificate page.

k. Click Done on the Signature Verification/Summary page.

l. Click Next on the Credentials/Signature Verification Settings page.

m. Click Done on the Credentials/Summary page.

n. Click Next on the SP Connection page.

Step 6

Activate and save the new settings.

Set the Connection Status to Active on the SP Connection/Activation & Summary page, and then click Save .

Step 7

Stop.

You have completed this procedure.

Export SP Metadata from DMM

Before you can use Cisco DMS in federation mode, you must export data from DMS-Admin in the form of an SP configuration file. Later, you will import this file into your IdP.

Before You Begin

  • Make sure that your DMM appliance is running in embedded authentication mode or LDAP mode.
  • Log in to DMM as its superuser .

Procedure

Step 1 Click Administration .

Step 2 Choose Security > Authentication .

Step 3 Check the Federation check box.

Step 4 Click Export .

Step 5 Save the exported file to your client PC or laptop computer as dms_sp_config.xml .

Note See the technical documentation or tutorials for your IdP to understand how it imports SP configuration files. Alternatively, see the topic for your IdP platform in this chapter’s “IdP Configuration Examples” section.

Step 6 Stop. You have completed this procedure.

 

Related Topics

Import IdP Metadata into DMM

Before you can use Cisco DMS in federation mode, you must export data from your IdP in the form of an IdP configuration file. This topic explains how to use the exported file after you generate and save it.

Before You Begin

  • See the technical documentation or tutorials for your IdP to understand how it exports configuration files for an SP (such as DMM) to import. Alternatively, see the topic for your IdP platform this chapter’s “IdP Configuration Examples” section.
  • Rename the exported IdP configuration file idp_ <type> .xml . For example:

– idp_ openam .xml

– idp_ shibboleth .xml

– idp_ pingfederate .xml

  • Make sure that your DMM appliance is running in embedded authentication mode or LDAP mode.
  • Log in to DMM as its superuser .

Procedure

Step 1 Click Administration .

Step 2 Choose Security > Authentication .

Step 3 Click Federation to choose it as your authentication mode.

Step 4 Click Import .

Step 5 Choose and upload the IdP file ( idp_ <type> .xml ) that you saved previously.

Step 6 Enter the necessary LDAP information to use your Active Directory server.

Step 7 Stop. You have completed this procedure.

 

Related Topics

Bypass External Authentication During Superuser Login, as Needed

Your DMM server features a special login form, which rejects every username except superuser . You use this special form whenever Cisco DMS runs in federation mode or an error has prevented migration from one authentication mode to another.

Procedure

Step 1 Go to http:// <FQDN> :8080/dmsadmin/admin/login .

a. Enter superuser in the Username field.

b. Enter the corresponding password in the Password field.

c. Click Log In .

Step 2 Stop. You have completed this procedure.

 

Related Topics

Reference

Elements to Choose and Enable an Authentication Mode

Navigation Path

Administration > Security > Authentication > Select Mode

 

Table 8-1 Elements for Authentication Modes

Element
Description

Authentication Mode Area

Embedded

Requires users who log in to DMM to authenticate against a user account database that is native to DMM. This database is independent of every other type of authentication that you might use in your network.

LDAP

Automatically deletes all user accounts except superuser . Requires future users to authenticate against the user account data from your Active Directory server when they log in to DMM.

Microsoft Active Directory is the only LDAP implementation that we support in this release.

Federation

Automatically deletes all user accounts except superuser . Requires future users to authenticate themselves to your IdP when they log in to DMM.


Federation Mode Elements Area

Last Successfully Configured IdP

This value becomes populated for the first time after you succeed at least once in importing configuration metadata into DMM from your IdP.

This element is visible in federation mode only.

IdP Configuration File

Provides the means to import configuration metadata that you previously exported from your IdP and saved to a file. Click Import to browse for the file, which you can then import.

This element is visible in federation mode only.

Last Configured IdP

(CSCtn15472) While it names an IdP explicitly, this value does not necessarily identify the IdP in current use. Instead, this value describes only your most recent attempt to import configuration metadata from an IdP, without regard for whether the attempt failed or succeeded.

This element is visible only in federation mode. It becomes populated for the first time after you attempt at least once to import IdP metadata.

Tip Compare this value to the “Last Successfully Configured IdP” value. When they differ, you know that your latest such attempt actually failed.

(SP Configuration File) Export

Provides the means to export configuration metadata from DMM. Click Export to begin browsing for a folder on a locally mounted drive where you can save the exported config file.

Later, you will import this file into your IdP.

This element is visible in federation mode only.

Enable Authentication Test

Helps you to test whether your federation mode settings are correct and will allow SSO for your ordinary users.

Check this check box to expose UI elements that are otherwise hidden. Clear this check box to hide such elements.

Test Username

Enter a username that your IdP already knows. Do not use the “superuser” username. This element is visible only while the Enable Authentication Test check box is checked.

Test User Password

Enter the password that corresponds to the test username. This element is visible only while the Enable Authentication Test check box is checked.


LDAP Configuration Area

Anonymous

Enables or disables an anonymous connection between your DMM appliance and your Active Directory server.

  • An anonymous connection is suitable when you want to see or use public information on the Active Directory server.
  • In contrast, when you want to see or use privileged information on your Active Directory server, the server will require you to enter login credentials to prove that you have sufficient access rights.

In the latter case, your Active Directory server will reject any attempt to log in anonymously.

This check box is available to you only when you choose LDAP mode or federation mode.

Host

Enter the routable IP address or DNS-resolvable hostname for the Active Directory server. This field is available to you only when you choose LDAP mode or federation mode.

Port

Enter the TCP port number that your Active Directory server uses for communications. This field is available to you only after you choose LDAP mode or federation mode.

The Active Directory port number by default is:

  • 389 for LDAP communications.
  • 636 for LDAPS ( Secure LDAP , or LDAP over SSL ) and SSO communications.

Administrator DN

Enter the distinguished name of the Active Directory server administrator.

This field is available to you only after you choose LDAP mode or federation mode and uncheck the Anonymous check box.

Tip See administrator DN.

Password

Enter the password that is associated with the Administrator DN.

This field is available to you only after you choose LDAP mode or federation mode and uncheck the Anonymous check box.

Use SSL Encryption

The check box to enable or disable encrypted sign-on. This check box is available to you only when you use LDAP mode or federation mode.

Note Whenever you enable SSL or install a new SSL certificate for LDAP, you must restart Web Services (Tomcat) from AAI. Otherwise, LDAP users cannot log in and the new (or newly enabled) SSL certificate cannot take effect. Also — if your DMM server is one half of a failover pair — the Tomcat restart will trigger immediate failover. (CSCtl09696)

  • Check the check box to enable encryption.
  • Uncheck it to disable encryption.

Enabling SSL causes the connections between your DMM appliance and your Active Directory server to use LDAPS. An LDAPS connection is suitable when you want to prevent untrusted third parties from reading credentials that the servers exchange.

Active Directory Certificate File

Helps you to upload the digital certificate that your Active Directory server uses for LDAPS communications. This field is available to you only while the Use SSL Encryption check box is checked.


Command Buttons

Update

Saves and applies your work on the Authentication Mode property sheet.

Cancel

Discards your work on the Authentication Mode property sheet and resets all values to their previous configuration.

Related Topics

Elements to Define, Validate, and Add LDAP Filters

Navigation Path

Administration > Security > Authentication > Define Filter

 

Table 8-2 Elements for Filters

Element
Description

Description

Enter a human-readable description for the filter.

User Base DN

Enter the distinguished name of the Active Directory user base that you will search.

User Filter

Enter a user filter to limit the number of matching user accounts to import from the user base that you specified.

User Group (in DMM)

Choose or create a user group to associate with the filter. At the very least, the list includes these options.

  • All Users Group
  • Create a New User Group
  • Digital Signage Users

Command Buttons

Add

Adds the filter, exactly as entered, without first validating it.

Validate

Validates the filter to confirm, before you add it, that it will return meaningful results.

Clear

Clears all entries from the Define Filters property sheet.

Related Topics

Elements to Use LDAP Bookmarks for Synchronization

Navigation Path

Administration > Security > Authentication > Synchronize Users

 

Table 8-3 Elements for Bookmarks

Element
Description

LDAP Bookmarks property sheet

Synchronization

One of the following types.

  • Initial
  • Update
  • Overwrite
  • Delete

 

Note When you click Delete on the LDAP Bookmarks sub-tab, we ask you whether to delete groups and policies. When you choose Yes, we delete all of the following from Cisco DMS.
 • All user accounts that match the filter.
 • The particular user group that is associated to the filter.
 • All access policies associated to the particular user group.

The deletion process can take as long as 1 minute to finish. (CSCtn22370)

Command Buttons

Update

Submits your selections for the type of synchronization and the scope of access that you chose and configured. Synchronization of the specified type starts immediately.

Cancel

Resets all entries to their previous values on the LDAP Bookmarks property sheet.

  • Discards all changes to the configuration of behaviors for synchronizations.
  • Discards all changes to the scope of access.

Related Topics

Elements to Schedule Synchronization

Navigation Path

Administration > Security > Authentication > Synchronize Users

 

Table 8-4 Elements for Scheduling

Element
Description

Scheduling property sheet

Synchronization Mode

Enables one synchronization mode to receive updated user account information from an Active Directory server. We support two such modes but they are mutually exclusive. Whenever you enable one, you disable the other. Click either Manual Synchronization or Automatic Synchronization .

Command Buttons

Update

Submits your selections for the type of synchronization and the scope of access that you chose and configured. Synchronization of the specified type starts immediately.

Cancel

Resets all entries to their previous values on the Scheduling property sheet.

  • Discards all changes to the configuration of behaviors for synchronizations.
  • Discards all changes to the scope of access.

Related Topics

Elements to Manage Attributes

Navigation Path

Administration > Security > Authentication > Manage Attributes

 

Table 8-5 Elements for Attributes Management

Element
Description

DMM Attribute Name

Values that DMS-Admin uses to describe and identify various attributes that it associates with each user account. You cannot change the values in this column. They are for your reference only, to help you enter suitable values (and recognize suitable values when you see them) in the LDAP Attribute Name column and the Values to Use by Default column.

LDAP Attribute Name

Values that your Active Directory server uses — which correspond one-to-one with values in the DMM Attribute Row column — to describe and identify attributes of each user account. In its factory-default configuration, DMS-Admin prepopulates all fields in this column with the most commonplace values that Active Directory servers use for this purpose. When the values for these attributes differ on your Active Directory server or when you prefer to import objects that use other Active Directory attributes, you can edit the values in this column.

Values to Use by Default

Enter text to insert automatically when the value is blank for the corresponding attribute in an Active Directory user account that you import or synchronize. To ensure that DMS-Admin imports each valid user account that matches a filter, we recommend that you enter values for these attributes:

  • First Name
  • Last Name

For your convenience, you can also enter values to insert automatically when the values are blank for other attributes — such as Company, Department, or Phone Number — but this is optional.

Note You cannot enter a value to use by default as the Login User Name value.

Ignore User Account Control Flags

Tells DMM to ignore whether your Active Directory server makes use of the User Account Control Flags attribute. DMM expects to find this attribute on your Active Directory server and, when the attribute is not present, authentication fails.

Command Buttons

Reset to Factory Default

Returns all values in the LDAP Attribute Name column to the most commonplace values that Active Directory servers use. If you entered different values manually because the labels for these attributes differ on your Active Directory server or because you prefer to import user accounts that use other Active Directory attributes, DMS-Admin deletes what you entered.

Update

Saves and applies your work in the Manage Attributes property sheet.

Related Topics

Sample SP Configuration File from DMM

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!--
! DMS SAML2 Service Provider Metadata
!
! Actual Service Provider configuration for the IDP will be instantiated
! from this template and be deposited onto the IDP.
! (Auto-generated on/at: Wed May 11 16:58:14 PDT 2011)
!
! Copyright (c) 2011 Cisco Systems, Inc.
!-->
<EntityDescriptor entityID="http://DMMSP.example.com:8080/opensso" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
<SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
 
<KeyDescriptor>
<ds:KeyInfo>
<ds:KeyName>tomcat</ds:KeyName>
<ds:X509Data>
<ds:X509SubjectName>/C=US/ST=CA/L=SJ/O=CISCO/OU=CISCO/CN=DMMSP.example.com</ds:X509SubjectName>
<ds:X509IssuerSerial>
<ds:X509IssuerName>DMMSP.example.com</ds:X509IssuerName>
<ds:X509SerialNumber>1304558251</ds:X509SerialNumber>
</ds:X509IssuerSerial>
<ds:X509Certificate>Mk6g1VAwAIGUk0QTNwaEzqUECAczVzAMCSDsUIgAQELICqwFQhOABhGJiQwgBBYCkAHAIB9DGMQE COBEcGAAT0Qg4wBBMMVTzVzC1DEQAM8KlAQVKNDwDMBGF0TxWJACA0YNENgQxCSADEVNlQUwQxDV BDbAQ0M8pvGTNUFyMtzwTYxTAMVTMMAxx3EMLEcTDDFMvzNEmwcTMNco2LmhgTVw2MTaMAmvx1ALMOQADBkjVwACMBGNTh0F1BQVJJQAAUM1BSDQwTHAsxAVgMlNMjTCVEQEEgzCwEUCAAQxh8Y0GkMMBZZgTwSVNX0EUBglbgRvgwJrADA5QYF32B9PNQEBVJANQIBb5K8YwNUQNYo0aQDjDJyMbhjswjcDgAM0IYJIoAGAGBr/qw1adeTiX6wNGwl+Pn2rhopPL7cCzUI2aNCNyK+D99sLujKL/kjyCBZ9lqKPeCArxWfKycC3/QqgO/SNz33b8JSh6iG35kVwA3OMZplEtLX4CfBkdsXYTVaKIRPRLMSOH9u9vH6ELFgSzl8dH/tL1o3aJADhnG4gcFA8tGE8QIXZBdBQdNwlDYj1AAAARYsKS6wV2vCZEgTNEIMAQbvD A87sb03cvDpQUCJ5SQ0O/ 4xQA531HhBHSCDOFbUlq+ PeTKB4dkGsIst9BPaIr43bWO3zfkMbrU2A WNu+ dPcBZpO1raWmP2I8ZErlDYPJSEstzmaC30kkeXg4nfe10KCx1QH8BAQusegy38+ oh8NLYw3N dzQl5vs=
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
 
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://DMMSP.example.com:8080/opensso/SPSloRedirect/metaAlias/sp" ResponseLocation="http://DMMSP.example.com:8080/opensso/SPSloRedirect/metaAlias/sp"/>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://DMMSP.example.com:8080/opensso/SPSloPOST/metaAlias/sp" ResponseLocation="http://DMMSP.example.com:8080/opensso/SPSloPOST/metaAlias/sp"/>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="http://DMMSP.example.com:8080/opensso/SPSloSoap/metaAlias/sp"/>
<ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://DMMSP.example.com:8080/opensso/SPMniRedirect/metaAlias/sp" ResponseLocation="http://DMMSP.example.com:8080/opensso/SPMniRedirect/metaAlias/sp"/>
<ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://DMMSP.example.com:8080/opensso/SPMniPOST/metaAlias/sp" ResponseLocation="http://DMMSP.example.com:8080/opensso/SPMniPOST/metaAlias/sp"/>
<ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="http://DMMSP.example.com:8080/opensso/SPMniSoap/metaAlias/sp" ResponseLocation="http://DMMSP.example.com:8080/opensso/SPMniSoap/metaAlias/sp"/>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</NameIDFormat>
<AssertionConsumerService index="0" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://DMMSP.example.com:8080/opensso/Consumer/metaAlias/sp"/>
<AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="http://DMMSP.example.com:8080/opensso/Consumer/metaAlias/sp"/>
<AssertionConsumerService index="2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="http://DMMSP.example.com:8080/opensso/Consumer/ECP/metaAlias/sp"/>
</SPSSODescriptor>
</EntityDescriptor>

Summary Configuration Sample (PingFederate)

SP Connection

Connection Type

Connection Role:

SP

Browser SSO Profiles:

true

Protocol:

SAML 2.0

Connection Template:

No Template

WS-Trust STS:

false

Connection Options

Browser SSO:

true

Attribute Query:

false

SaaS Provisioning:

false

General Info

Partner’s Entity ID (Connection ID):

http://example.cisco.com:8080/opensso

Browser SSO

SAML Profiles

IdP-Initiated SSO:

false

IdP-Initiated SLO:

false

SP-Initiated SSO:

true

SP-Initiated SLO:

false

Assertion Lifetime

Assertion Minutes Before:

5

Assertion Minutes After:

5

Assertion Creation

Identity
Mapping

Enable
Transient Identifier:

true

Include
additional attributes:

true

Attribute
Contract

Attribute:

SAML_AUTHN_CTX

Attribute:

UID

IdP Adapter Mapping

Adapter instance name:

LDAP 9

Authentication Type

Authentication Type:

Single-Factor Authentication

Adapter
Instance

Selected
adapter:

LDAP 1

Assertion Mapping

Adapter:

LDAP Authentication Service 2.2

Data Store or Assertion:

 

Use only the Adapter Contract values in the SAML assertion

Attribute
Contract Fulfillment

SAML_AUTHN_CTX:

urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport (Text)

UID:

subject10 (Adapter)

Protocol Settings

Assertion Consumer
Service URL

Endpoint URL:

https://example.cisco.com:8443/opensso/Consumer/metaAlias/sp (POST)

Allowable
SAML Bindings

Artifact:

false

POST:

true

Redirect:

true

SOAP:

true

Protocol Settings

Signature Policy

Require digitally signed
AuthN requests:

true

Always sign the SAML Assertion:

true

Encryption Policy

Status:

Inactive

Credentials

Inbound SOAP Authentication Type

SOAP Authentication Type:

Use Digital Signatures to guarantee payload in Browser SSO profile

SSL required:

true

Digital
Signature
Settings

Selected Certificate:

CN= <your_organization> ,
O= <your_department> ,
L= <your_city_or_village> ,
ST= <your_state_or_province> ,
C= <your_country>

Include Certificate
in KeyInfo:

true

Selected
Signing Algorithm:

RSA SHA1

Signature Verification

Trust Model

Trust Model:

Unanchored

Signature Verification Certificate

Selected Certificate:

CN= < FQDN_of_your_DMM_SP > ,
OU= < your_organization > ,
O= < your_department > ,
L= < your_city_or village > ,
ST= < your_state_or_province > ,
C= < your_country >

Exported IdP Metadata Sample from OpenAM

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<EntityDescriptor entityID="dmsIdp" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
<IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
MJEwVFggTTQ1MUwD9w0kQACIQNICQQWBGBYlAqqAMBGUzAwAEkVsiagAELKkCBkDCADdhAUIQIGE CYABEMTxwVzNBKQlNQZDMAlNCEQ1ADJzAKC0E4QgQSBExwGGVwzM0AAgQOVDUDT0A8cCNTxMFBVV BxxjNambbJAQRbThnMxjlMNFYMm8cpT2mDovLMTvENv4pAJIw2yNDRAYDMMTAG0wOyET3MLExgMw ZEMAAVk80JDVMVT1TSghThEMxBwjAU1zkwFMYEODCAQgH0MGQQGAJCNLEUNBQEBsCCBAwQVMlQAx DGgwkJ5EAY9vMADP2y0NbJIQo0jV5RaXw8YbsQsTVQDjx5ZNKNZaUgMBByUDjhcYjN2wJBSWQ0bNABmAo2eD4JQ1QAhEVyPDgAQEMZBUIAtNdgrxA0BcYIB9QuG4aWYHGX/ LcxHcYOES0MIYciud6KmI+/ kq/ YpRbA30QYctD0uax/ 0M7BUD/SMT+P1kQhA9dCLiOeu2WB2dKFWWOwcLIhgne7omCI+ozijrImy+4C3fz9zC/VrBA3bQZMcnsE6YbZJDC7IhAjNAEAoQNZ5gGAKxBYEABzXjgAQwcDpvFYK1yNqr wArSlA7b3Vkhn42iQVjvj8I3No2ssay4LZyBsffkrm+ gATatC/ HvyyNGoapGS9K4fLZNzBaXDW99/ 728x7bGciRWFdx4VOdPABkis+ a1Had9Blj8uCupvRp/ wkRkP+ 6hldOYEWQyVmrwid02g3S5Gtb+ ErQO7KA5G1wKvrw=
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<ArtifactResolutionService index="0" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="http://OpenAM.example.com:8080/opensso/ArtifactResolver/metaAlias/idp"/>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://OpenAM.example.com:8080/opensso/IDPSloRedirect/metaAlias/idp" ResponseLocation="http://OpenAM.example.com:8080/opensso/IDPSloRedirect/metaAlias/idp"/>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://OpenAM.example.com:8080/opensso/IDPSloPOST/metaAlias/idp" ResponseLocation="http://OpenAM.example.com:8080/opensso/IDPSloPOST/metaAlias/idp"/>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="http://OpenAM.example.com:8080/opensso/IDPSloSoap/metaAlias/idp"/>
<ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://OpenAM.example.com:8080/opensso/IDPMniRedirect/metaAlias/idp" ResponseLocation="http://OpenAM.example.com:8080/opensso/IDPMniRedirect/metaAlias/idp"/>
<ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://OpenAM.example.com:8080/opensso/IDPMniPOST/metaAlias/idp" ResponseLocation="http://OpenAM.example.com:8080/opensso/IDPMniPOST/metaAlias/idp"/>
<ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="http://OpenAM.example.com:8080/opensso/IDPMniSoap/metaAlias/idp"/>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</NameIDFormat>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://OpenAM.example.com:8080/opensso/SSORedirect/metaAlias/idp"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://OpenAM.example.com:8080/opensso/SSOPOST/metaAlias/idp"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="http://OpenAM.example.com:8080/opensso/SSOSoap/metaAlias/idp"/>
<NameIDMappingService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="http://OpenAM.example.com:8080/opensso/NIMSoap/metaAlias/idp"/>
<AssertionIDRequestService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="http://OpenAM.example.com:8080/opensso/AIDReqSoap/IDPRole/metaAlias/idp"/>
<AssertionIDRequestService Binding="urn:oasis:names:tc:SAML:2.0:bindings:URI" Location="http://OpenAM.example.com:8080/opensso/AIDReqUri/IDPRole/metaAlias/idp"/>
</IDPSSODescriptor>
</EntityDescriptor>

Exported IdP Metadata Sample from Shibboleth

<EntityDescriptor entityID=”https://sso.example.com/idp/shibboleth”
xmlns=”urn:oasis:names:tc:SAML:2.0:metadata”
xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”
xmlns:shibmd=”urn:mace:shibboleth:metadata:1.0”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”>
 
<IDPSSODescriptor protocolSupportEnumeration=”urn:mace:shibboleth:1.0 urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol”>
 
<KeyDescriptor>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIICRTCCAa6gAwIBAgIETOrk+jANBgkqhkiG9w0BAQUFADBmMQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCQ0ExCzAJBgNVBAcTAlNKMQ4wDAYDVQQKEwVDSVNDTzEOMAwGA1UECxMFQ0lTQ08xHTAbBgNV
BAMTFGZydWl0bG9vcHMuY2lzY28uY29tMCAXDTEwMTEyMjIxNDczOFoYDzIxMTAxMDI5MjE0NzM4
WjBmMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExCzAJBgNVBAcTAlNKMQ4wDAYDVQQKEwVDSVND
TzEOMAwGA1UECxMFQ0lTQ08xHTAbBgNVBAMTFGZydWl0bG9vcHMuY2lzY28uY29tMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQCX0tTliXR7pGh9NNEKbIkChNB0t/H+2ysm4xr1Y60+hFssJGGx
qnNv8UEqH7SIk7Z9eDBW6lJreiH3KtSWIJBvtV1hLGZAlwPTu/b6GzVHGX9uZaj3Jyw0N8rul8k8
BoTsdNag7ZhQ7vIfcQ1HjLw9RT3u+n5ZkD+hbwEKtKePEwIDAQABMA0GCSqGSIb3DQEBBQUAA4GB
AA932Gf5lEY1c3w/ALuEXiDdtLnzRrNZxF7ZneDPfnjygNMOLgYTwCARdjdW40Xurd2RGSJC3MYJ
bhqMIStSTbYPBB6KLuEWkk+AW+/uprX5T49SY6hS918tcErmWdW0CYFlIiRa2hMaJz6AbWAqKR80
+n5IWxwEOlkmOPdWd1B/
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<ArtifactResolutionService Binding=”urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding”
Location=”http://sso.example.com:8080/idp/profile/SAML1/SOAP/ArtifactResolution”
index=”1”/>
 
<ArtifactResolutionService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:SOAP”
Location=”http://sso.example.com:8080/idp/profile/SAML2/SOAP/ArtifactResolution”
index=”2”/>
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
 
<SingleSignOnService Binding=”urn:mace:shibboleth:1.0:profiles:AuthnRequest”
Location=”http://sso.example.com:8080/idp/profile/Shibboleth/SSO” />
<SingleSignOnService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST”
Location=”http://sso.example.com:8080/idp/profile/SAML2/POST/SSO” />
 
<SingleSignOnService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign”
Location=”http://sso.example.com:8080/idp/profile/SAML2/POST-SimpleSign/SSO” />
<SingleSignOnService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect”
Location=”http://sso.example.com:8080/idp/profile/SAML2/Redirect/SSO” />
 
<SingleSignOnService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:SOAP”
Location=”http://sso.example.com:8080/idp/profile/SAML2/SOAP/SSO”/>
 
</IDPSSODescriptor>
 
<AttributeAuthorityDescriptor protocolSupportEnumeration=”urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol”>
 
<KeyDescriptor>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIICRTCCAa6gAwIBAgIETOrk+jANBgkqhkiG9w0BAQUFADBmMQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCQ0ExCzAJBgNVBAcTAlNKMQ4wDAYDVQQKEwVDSVNDTzEOMAwGA1UECxMFQ0lTQ08xHTAbBgNV
BAMTFGZydWl0bG9vcHMuY2lzY28uY29tMCAXDTEwMTEyMjIxNDczOFoYDzIxMTAxMDI5MjE0NzM4
WjBmMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExCzAJBgNVBAcTAlNKMQ4wDAYDVQQKEwVDSVND
TzEOMAwGA1UECxMFQ0lTQ08xHTAbBgNVBAMTFGZydWl0bG9vcHMuY2lzY28uY29tMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQCX0tTliXR7pGh9NNEKbIkChNB0t/H+2ysm4xr1Y60+hFssJGGx
qnNv8UEqH7SIk7Z9eDBW6lJreiH3KtSWIJBvtV1hLGZAlwPTu/b6GzVHGX9uZaj3Jyw0N8rul8k8
BoTsdNag7ZhQ7vIfcQ1HjLw9RT3u+n5ZkD+hbwEKtKePEwIDAQABMA0GCSqGSIb3DQEBBQUAA4GB
AA932Gf5lEY1c3w/ALuEXiDdtLnzRrNZxF7ZneDPfnjygNMOLgYTwCARdjdW40Xurd2RGSJC3MYJ
bhqMIStSTbYPBB6KLuEWkk+AW+/uprX5T49SY6hS918tcErmWdW0CYFlIiRa2hMaJz6AbWAqKR80
+n5IWxwEOlkmOPdWd1B/
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
 
<AttributeService Binding=”urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding”
Location=”http://sso.example.com:8080/idp/profile/SAML1/SOAP/AttributeQuery” />
<AttributeService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:SOAP”
Location=”http://sso.example.com:8080/idp/profile/SAML2/SOAP/AttributeQuery” />
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
</AttributeAuthorityDescriptor>
</EntityDescriptor>

Exported IdP Metadata Sample from PingFederate

<md:EntityDescriptor entityID="saml2" cacheDuration="PT1440M"
ID="OUEOtB9WV9lj-tGu57Lzdbwmah." xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
<md:IDPSSODescriptor 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>
MIICUzAgI0xCzAJBgNVGATL3DQEBBQUA6reRuMA0GCSqGSIbCCAbygAwIBMGBAYTAl
VTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMREwDwYDVQQHEwhTYW4gSm9zZTEeMBwGA1UE
ChMVRGln0ZW1zMRYwFAYaNZWRpYSBTeXNDVQQXRhbCBDEw1DaXNjbyBTeXN0ZW1zMB
4XDTExMTAxMzAwMjgxMloXDTEyMTAxMjAwMjgxMlowbTELMAkGA1UEBhMCVVMxEzAR
BgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMR4wHAYDVQQKExVEaW
dpdGFsIE1lZGlhIFN5c3RlbXMxFjAUBgNVBAMTDUNpc2NvIFN5c3RlbXMwgZ8wDQYJ
KoZIhvJAoGBALaYHMXD2DcNAQEBBQADgY0AMIGrFA+B1GubRCQIsqtpv0sHHdmLiJ8
CpuGtIgpHGBYHyKhPPS506YUbpduEViHM4MAqO0c0TKG8JCdhpXgoHI+/suo6zgkm6
x6UOZsW36+FxlUOgO4hsGG3rpNtgkLSd4YrnlwVCdb0FPgsvE58zbptosAQKF5R8iq
NLAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAedOWz2UZctWwUxSVhTZ1pE39wDTaf40X
0yN9vZiV2O3naP7rwkwles1svozpz5Cw/GJITznvRM2ez3agYaOsnz4FuDARjv3/cz
SED+6uMlv8xsk6gQ1zD3dJmyN2bJL/ENc+6bw8jepPGzyZBv+GwJwLeobKTgcCUI6X
1rIDn1U=
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
<md:SingleSignOnService
Location="https://idp.example.com:9031/idp/SSO.saml2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" />
<md:SingleSignOnService
Location="https://idp.example.com:9031/idp/SSO.saml2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" />
<md:SingleSignOnService
Location="https://idp.example.com:9031/idp/SSO.saml2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" />
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="SAML_AUTHN_CTX" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" />
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="UID" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" />
</md:IDPSSODescriptor>
</md:EntityDescriptor>

FAQs and Troubleshooting

LDAP (Active Directory) FAQs

Q. Which Active Directory releases does Cisco DMS support?

Our completed tests succeeded as follows.

Windows Active Directory Server 2000

  • Cisco DMS 5.3

Windows Active Directory Server 2003

  • Cisco DMS 5.3

Windows Active Directory Server 2008R2

  • Cisco DMS 5.3

Federation Mode (SSO) FAQs

Q. Are there any special APIs to use federation mode ?

No. We support one set of API calls that work identically across all supported authentication modes. See http://developer.cisco.com .

Q. Does DMM perform trust validation of certificates that it imports with IdP metadata?

Yes.

Q. Do you support any use of certificate revocation lists?

No. Not in this release.

Q. Can I use one browser to connect simultaneously to more than one DMM appliance?

No. Each time that you connect to an additional instance, you are logged out of any prior instance in that browser. However, you can use multiple browsers together for this purpose.

Q. Why would user sessions time out for DMM users after a different interval than I set in DMM?

This can happen when session timeout values differ between your DMM appliance and your IdP. Reconfigure these servers to share one identical session timeout value.

Error Message FAQs

Q. Why does an error message state that an Active Directory password is not valid?

Explanation A “User must change password at next login” flag might be set on your Active Directory server. While this flag is set, the affected user cannot log in to any Cisco DMS component. DMS-Admin cannot change any password on your Active Directory server.

Recommended Action Use features that your Active Directory server provides for this purpose.

Q. Why does an error message state that filter validation has failed?

Explanation Filters fail when they point to empty containers. They also fail in response to filter expressions that includes any spaces.

Recommended Action Make sure on your Active Directory server that your filter did not refer to an empty organizational unit (OU) container. Confirm also that your filter expression does not contain even one space.

Q. Why would my API calls receive an HTTP 401 Unauthorized error?

Recommended Action When you use federation mode, enable ECP on your IdP server.

Network Policy FAQs

Q. When I use LDAP authentication with Cisco DMS, which ports must remain open in my network?

Your DMM appliance accepts user authentication requests securely through port 443 . DMM then passes these requests securely to your Active Directory server through port 389 . Also, SSL uses port 636 .

User Exclusion FAQs

Q. Can I block Cisco DMS access to one particular Active Directory user account, when it is among the matched results for an otherwise useful LDAP filter?

Yes. Extend your query to include a logical NOT ( ! ) operator for an attribute whose value is unique to this user. This example uses the LDAP “ samAccountName ” attribute name, which DMM uses by default to populate the corresponding login name for DMM. However, if your Active Directory server uses any other attribute name than “ samAccountName ” for this purpose, you must update the example syntax accordingly when you extend your query.

(&(currentFilter)(samAccountName!=username-to-be-excluded))
 

Tip Information on the Manage Attributes property sheet in DMS-Admin confirms whether your Active Directory server uses the “samAccountName” attribute name.

Was this Document Helpful?

FeedbackFeedback

Contact Cisco