Analytics and Automation Software : Cisco Tidal Enterprise Scheduler

Reconnaissance de nom de domaine : Le pseudonyme est différent du nom de domaine

17 octobre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document décrit une question dans le Cisco Tidal Enterprise Scheduler (TES) qui se produit quand un utilisateur ouvre une session au client web de marée du programmateur d'entreprise (TES) utilisant un domaine de procédure de connexion qui est réellement un pseudonyme pour le domaine interne LDAP/AD.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Les informations dans ce document sont basées sur 6.0.2.101 ou plus tard.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Problème

Quand un utilisateur ouvre une session au client web TES utilisant un domaine de procédure de connexion qui est réellement un pseudonyme pour le domaine interne LDAP/AD (le dernier composant de domaine (le C.C)) défini pour cet utilisateur, le domaine interne ne s'assortit pas avec le domaine enregistré dans TES pour cet utilisateur. L'utilisateur voit que vous n'êtes pas message d'erreur autorisé et ne pouvez pas ouvrir une session. Afin de réparer ceci, les utilisateurs doivent figurer ce qu'est leur effectif, domaine non-aliased dans LDAP/AD. Puis, veillez à utiliser le nom interne en définissant des utilisateurs dans TES, qui inclut créer le super utilisateur initial pendant l'installation.

Solution

Changez le comportement par défaut de sorte que le domaine de procédure de connexion soit ce qui est apparié avec l'article utilisateur TES. Ceci maintient le domaine de l'utilisateur cohérents pendant pour installer, en définissant des utilisateurs et en ouvrant une session à l'UI.

Résolution

Sysval 117 peut être placé pour restaurer la logique assortie de domaine interne précédent, ou pour essayer chacun des deux, par l'établissement du sysval_integer comme suit :

  1. Appariez seulement le nom de domaine de procédure de connexion de Windows avec l'article utilisateur dans TES (le nouveau comportement par défaut sinon spécifié).

  2. Appariez seulement le nom de domaine interne LDAP/AD avec l'article utilisateur dans TES (vieux comportement avant ce correctif).

  3. Essayez d'apparier le domaine de procédure de connexion de Windows, puis essayez d'apparier le nom de domaine interne LDAP/AD.

  4. Essayez d'apparier le nom de domaine interne LDAP/AD, puis essayez d'apparier le nom de domaine de procédure de connexion de Windows.

Remarque: En insérant ou en mettant à jour ce sysval, veillez à placer le champ de lstchgtm au temps en cours de sorte que la nouvelle valeur propage dans le cache de client.

Exemple :

MSSQL :

insert into sysval (sysval_id, sysval_integer, sysval_lstchgtm) values (117, 1, SYSDATETIME())

Oracle :

insert into sysval (sysval_id, sysval_integer, sysval_lstchgtm) values (117, 1, SYSDATE)

Pour les utilisateurs qui ont déjà fonctionné autour de cette question à côté de mettre leurs articles utilisateur à jour TES pour avoir les domaines internes, vous pouvez préserver le vieux comportement en plaçant le sysval à 2. valeurs 3 et 4 pouvez être utile transitioning du vieux comportement au nouveau comportement comme articles utilisateur êtes mis à jour avec leurs domaines de procédure de connexion au lieu de leurs domaines internes.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 113403