adedit and computer role assignments?

Showing results for 
Search instead for 
Do you mean 
Reply
Contributor I
Posts: 14
Registered: ‎10-24-2014
#1 of 3 6,805

adedit and computer role assignments?

I've noticed a weird quirk in DirectControl 2013.3 that I cannot explain.  Note that the quirk might actually be me rather than a software problem.  :-)

 

Let's say that I have a computer called computer01 joined to a zone called Access-By-System:

 

  Local host name: computer01

  Joined as: computer01.my.domain

  Zone: my.domain/Servers/Unix/Centrify/Zones/UNIX/Access-By-System

  CentrifyDC mode: connected

 

And I have a role called 'UNIX Login/Access-By-System'.

 

I can open DirectManage and select computer01 from my.domain/Zones/UNIX/Access-By-System/Computers, select Role Assignments, right click and choose Assign Role..., then go through the roles UI, select a (for example) AD group, then click Cancel and in adedit I am able to do:

 

  select_zone "cn=....myzonehere.../computer01.my.domain"

  new_role_assignment adGroupName@my.domain "UNIX Login/Access-By-System"

  svra

 

then everything is fine for creating a role assignment for computer01.  Everything looks as it should in DirectManage.

 

However, if I take another computer called computer02, do a successful adjoin, and then go directly to adedit to create a role assignment with the commands below:

 

  select_zone_computer computer02$@my.domain

  select_zone "cn=....myzonehere.../computer01.my.domain"

 

I get the following error:

 

  Scope computer02.my.domain not found

 

Definitely not what I'd expected.  If I repeat the process with DirectManage as shown above, I can select_zone zone/computer02.my.domain again.

 

Can someone shed some light on what's happening to either my computer object or SCP when I click the Assign Role... link and select an AD group (even if I Cancel)?  Something must be happening because I can reproduce this case every time, but I have been unable to glean anything yet when looking at SCP or Computer properties -- to try and look at differences between joined computers where role assignments work through adedit and those where they do not.

 

Any recommendations would be appreciated!

 

Posts: 961
Topics: 3
Kudos: 256
Blog Posts: 6
Ideas: 0
Solutions: 126
Registered: ‎07-06-2010
#2 of 3 6,800

Re: adedit and computer role assignments?

[ Edited ]

Hi,

 

The reason is because in the 2nd scenario, a Computer level zone to store the role assignment does not yet exist.

 

You don't see this error when using DirectManage because when you click on the computer and expand, the computer zone is automatically created for you.

 

Therefore ammend your code to, before the role assignment, check if the computer zone exist.  If it does, perform your role assignment, if not, create the computer zone, then perform the role assignment.

 

Regards,

Felderi Santiago
VP of Enterprise Solutions
Centrify Corporation
Found my response helpful? Click the Kudos button!
Follow Centrify:
Highlighted
Contributor I
Posts: 14
Registered: ‎10-24-2014
#3 of 3 6,773

Re: adedit and computer role assignments?

Your advice was spot-on.  Thanks, Fel!

 

I ended up doing select_zone, catch, create_zone computer, catch, select_zone, catch, return.  What I wrote could be a heckuva lot better but it does its job.  Here's what I ended up doing (code not checked for errors -- typing this in real time).  Success == return 0, 1 otherwise.

 

proc myComputerSelectFunction { adDomain myZone myComputer } {

    set retVal 1

 

    if { [ catch { select_zone $myZone/$myComputer.$adDomain } selectZoneErr ] } {

        if { [ catch { create_zone computer $myComputer.$adDomain@$myZone } zoneCreateErr ]} {

            puts stderr "Error creating zone for $myComputer in $myZone: $zoneCreateErr"

        } else {

            if { [ catch { select_zone $myZone/$myComputer.$adDomain ] selectZoneErr  } {

                puts "Unable to select_zone $myZone/$myComputer.$adDomain: $selectZoneErr"

            } else {

                set retVal 0

            }

        }

    } else {

        set retVal 0

    }

 

    return $retVal

}

 

So, looks kind of ugly, and not really convinced that two calls to select_zone are the right away to go.  Maybe try to create_zone up-front and select_zone once if it catches a specific "zone exists" type of error in create_zone?

 

Semi pseudo-code:

 

proc myComputerSelectFunction { adDomain myZone myComputer } {

    set retVal 1

 

    # As a matter of course, try and create the computer zone up front.

    if { [ catch { create_zone computer $myComputer.$adDomain@$myZone } zoneCreateErr ]} {

        if { [ regexp {some-kind-of-zone-already-exists-text} $zoneCreateErr ] } {

            # We already have the computer zone; select it.  If we can't select_zone at this point, it's an error.

            if { [ catch { select_zone $myZone/$myComputer.$adDomain ] selectZoneErr  } {

                puts "Unable to select_zone $myZone/$myComputer.$adDomain: $selectZoneErr"

            } else {

                set retVal 0

            }

        } else {

            puts "Unable to create zone with $zoneCreateErr!  Exiting!"

        }

    }

 

    return $retVal

}