On 09/18/2012 03:22 PM, Alexander Bokovoy wrote:
On Tue, 18 Sep 2012, Petr Vobornik wrote:
On 09/18/2012 02:15 PM, Sumit Bose wrote:
On Tue, Sep 18, 2012 at 12:42:49PM +0200, Sumit Bose wrote:
On Mon, Sep 17, 2012 at 06:44:36PM +0300, Alexander Bokovoy wrote:

Following patch adds trust verification sequence to the case when we
establish trust with knowledge of AD administrative credentials.

As we found out, in order to validate/verify trust, one has to have
administrative credentials for the trusted domain, since there are
few RPCs that should be performed against trusted domain's DC's LSA
and NetLogon pipes and these are protected by administrative

Thus, when we know admin credentials for the remote domain, we can
perform the trust validation.


Just a short feedback. The patch is working as expected, for a newly
created trust Windows will send a TGS request to the IPA KDC without
explicit validation on the windows side. Currently I have some issues
in my test setup so that I can not give a full ACK atm.

ok, ACK.

Nevertheless it would be nice if Petr can check for any implications to
the web UI with respect to the status of the trust.

It shouldn't break Web UI but Web UI won't use it. In add command Web
UI uses only the command state (success/error). If the truststatus
text would be a part of command summary text, it can be displayed in
notification message (which fades after 3s) when comment 8 of
https://fedorahosted.org/freeipa/ticket/2977#comment:8 is implemented.
It is displayed as part of the output, truststatus property:
# ipa trust-add --type=ad --admin Administrator@ad.local --password
Active directory domain adminstrator's password:
Added Active Directory trust for realm "ad.local"
   Realm name: ad.local
   Domain NetBIOS name: AD
   Domain Security Identifier: S-1-5-21-16904141-148189700-2149043814
   Trust direction: Two-way trust
   Trust type: Active Directory domain
   Trust status: Established and verified

Would be good if you could take it in use.

I created a patch which uses it. See attached screenshots. It may be useful but, as I wrote, the message is displayed only for 3s, so some users might not have time to read it whole - message is too long.

It would be nice if it can be saved to ldap and return in show/find
commands? That way we can show it in search or details page. Or we can
implement trust-status $TRUST --admin $ADMIN --$password $PASSWORD
command to check the actual status anytime in a future.
We don't have an attribute to store the status. Neither it exists in

I'll talk to Simo if we can have one attribute like that but the price
of maintaining it up to date might be too much. On the other hand, we
can always invalidate value in the attribute when ipasam cannot use
shared trust account against trusted domain...

Running validation/verification as a separate command is possible but it
would be relatively resource-hungry and makes little use on its own. We
may couple it together with future multiple suffixes support (tickets
#2848, #2593) as fetching additional suffixes depends on validated trust

Petr Vobornik
From 7835f62bccefe69abc6122d4ddd6aa7c571f59b2 Mon Sep 17 00:00:00 2001
From: Petr Vobornik <pvobo...@redhat.com>
Date: Tue, 18 Sep 2012 17:12:59 +0200
Subject: [PATCH] Show trust status in add success notification

Web UI notification of 'Add verification step after trust creation'

 install/ui/add.js   |  9 +++++----
 install/ui/trust.js | 14 ++++++++++++++
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/install/ui/add.js b/install/ui/add.js
index d855879452e5812c8c7fbae7bc9d1ff9035f1a6e..06c9b325a58e31e3366529b552df29109117f847 100644
--- a/install/ui/add.js
+++ b/install/ui/add.js
@@ -52,7 +52,7 @@ IPA.entity_adder_dialog = function(spec) {
                         var facet = IPA.current_entity.get_facet();
-                        IPA.notify_success(that.get_success_message());
+                        IPA.notify_success(that.get_success_message(data));
@@ -66,7 +66,7 @@ IPA.entity_adder_dialog = function(spec) {
                     function(data, text_status, xhr) {
-                        that.show_message(that.get_success_message());
+                        that.show_message(that.get_success_message(data));
                         var facet = IPA.current_entity.get_facet();
@@ -86,7 +86,7 @@ IPA.entity_adder_dialog = function(spec) {
                         var result = data.result.result;
                         that.show_edit_page(that.entity, result);
-                        IPA.notify_success(that.get_success_message());
+                        IPA.notify_success(that.get_success_message(data));
@@ -102,7 +102,7 @@ IPA.entity_adder_dialog = function(spec) {
-    that.get_success_message = function() {
+    that.get_success_message = function(data) {
         var message = IPA.messages.dialogs.add_confirmation;
         return  message.replace('${entity}', that.subject);
@@ -183,6 +183,7 @@ IPA.entity_adder_dialog = function(spec) {
     // methods that should be invoked by subclasses
     that.entity_adder_dialog_create = that.create;
     that.entity_adder_dialog_create_add_command = that.create_add_command;
+    that.entity_adder_dialog_get_success_message = that.get_success_message;
diff --git a/install/ui/trust.js b/install/ui/trust.js
index 77e7cb38101773f787ae1cbedab5a4efe9edf82b..ad0d46e0b33b97b298a5c34441a8d066c81a1150 100644
--- a/install/ui/trust.js
+++ b/install/ui/trust.js
@@ -71,6 +71,7 @@ IPA.trust.entity = function(spec) {
+            factory: IPA.trust.adder_dialog,
             fields: [
                     name: 'cn',
@@ -162,4 +163,17 @@ IPA.trust.entity = function(spec) {
     return that;
+IPA.trust.adder_dialog = function(spec) {
+    spec = spec || {};
+    var that = IPA.entity_adder_dialog(spec);
+    that.get_success_message = function(data) {
+        return that.entity_adder_dialog_get_success_message(data) + '. ' + data.result.result.truststatus[0];
+    };
+    return that;
 IPA.register('trust', IPA.trust.entity);

<<attachment: trust-add-msg-established.png>>

<<attachment: trust-add-msg-waiting.png>>

Freeipa-devel mailing list

Reply via email to