Cisco Cisco TelePresence Video Communication Server Expressway 관리 매뉴얼
Device Authentication
This section provides information about the VCS's authentication policy and the pages that appear under the
Configuration > Authentication menu.
Configuration > Authentication menu.
About Device Authentication
Device authentication is the verification of the credentials of an incoming request to the Cisco TelePresence Video
Communication Server (VCS) from a device or external system. It is used so that certain functionality may be reserved
for known and trusted users, for example the publishing of presence status, collection of provisioning data, or the
ability to use resources that cost money like ISDN gateway calling.
Communication Server (VCS) from a device or external system. It is used so that certain functionality may be reserved
for known and trusted users, for example the publishing of presence status, collection of provisioning data, or the
ability to use resources that cost money like ISDN gateway calling.
When device authentication is enabled on a VCS, any device that attempts to communicate with the VCS is
challenged to present its credentials (typically based on a username and password). The VCS will then verify those
credentials, or have them verified, according to the authentication method, and then accept or reject the message
accordingly.
challenged to present its credentials (typically based on a username and password). The VCS will then verify those
credentials, or have them verified, according to the authentication method, and then accept or reject the message
accordingly.
VCS authentication policy can be configured separately for each zone and subzone. This means that both
authenticated and unauthenticated devices could be allowed to register to, and communicate with, the same VCS if
required. Subsequent call routing decisions can then be configured with different rules based upon whether a device
is authenticated or not.
authenticated and unauthenticated devices could be allowed to register to, and communicate with, the same VCS if
required. Subsequent call routing decisions can then be configured with different rules based upon whether a device
is authenticated or not.
The VCS attempts to verify the credentials presented to it by first checking against its on-box local database of
usernames and passwords. The local database also includes checking against credentials supplied by Cisco TMS if
your system is using device provisioning. If the username is not found in the local database, the VCS may then
attempt to verify the credentials via a real-time LDAP connection to an external H.350 directory service. The directory
service, if configured, must have an H.350 directory schema for either a Microsoft Active Directory LDAP server or an
OpenLDAP server.
usernames and passwords. The local database also includes checking against credentials supplied by Cisco TMS if
your system is using device provisioning. If the username is not found in the local database, the VCS may then
attempt to verify the credentials via a real-time LDAP connection to an external H.350 directory service. The directory
service, if configured, must have an H.350 directory schema for either a Microsoft Active Directory LDAP server or an
OpenLDAP server.
You can also configure a VCS Expressway so that the credential checking of SIP messages is delegated, via a
traversal zone, to another VCS.
traversal zone, to another VCS.
Along with one of the above methods, for those devices that support NTLM challenges, the VCS can alternatively
verify credentials via direct access to an Active Directory server using a Kerberos connection.
verify credentials via direct access to an Active Directory server using a Kerberos connection.
The various VCS authentication entry points and credential checking methods are shown below:
Cisco Systems, Inc.
126