LDAP Trusted Domain???

Sort:
You are not authorized to post a reply.
Author
Messages
DavidO
Basic Member
Posts: 5
Basic Member

    Ok... just to give a little background information... and I'm sorry if it is long... I just don't want to leave anything out.

    We currently have LDAP setup so our domain users can login to lawson.  When a new user needs access we run a perl script that adds the user information into LDAP I guess (I didn't set that up, and the person who did has moved on).

    Here is the perl script (runs like this... create-adusers.pl -u username)
    #########################################################
    # CREATE-ADUSERS.PL must be ran using a domain account #
    # If not, getting the SID will fail   #
    # CREATE-ADUSERS.PL will generate for each provided user#
    # a adamProxy entry and will import that file using  #
    # ldifde ADAM command.     #
    # $cfgfile must be populated correctly   #
    #########################################################


    my $cfgfile="adusers.cfg";
    my $logfile="adusers.log";


    ###################################################### UTILITY FUNCTIONS ######################################################


    sub fatal
    {
     my($errorStr,$die) =@_;
     print "\nError: $errorStr";
     if ($die==1){
      die;
     }
    }

    sub deleteLogFile{
     unlink($logfile);
    }


    sub writelogFile{
     my ($string) = @_;
     open LOGFILE, ">>$logfile" or fatal("Can't open $logfile - won't be used",0); 
     print LOGFILE "$string\n";
     close LOGFILE;
    }

    sub startRedirectError{
     open(STDERR, ">>$logfile") or fatal("no error redirection on $logfile",0);
    }

    sub stopRedirectError{
     close STDERR;
    }

    sub loadcfg {
     my ($cfgfile,%hash) = @_;

     open F, $cfgfile or
      fatal "Installation config file '$cfgfile' is missing.";

     while () {
      chomp;
      next if /^#/;
      $hash{uc($1)} = $2 if (/^\s*([\S.]+?)\s*=[ \t]*(\S.*)/);
     }
     
     close F or
      fatal("Problem reading file '$cfgfile'.",1);
     
     return %hash;
    }


    ###################################################### UTILITY FUNCTIONS ######################################################


    main();


    sub main()
    {

     #ARGUMENT PARSING#
     if (@ARGV < 1 or $ARGV[0] eq "-h" or $ARGV[0] ne "-u"){
      usage();
     }

     shift @ARGV;
     foreach $user (@ARGV) {
         push(@usernames,$user);
                next;
            }
     if (@usernames==0){
      usage();
     }

     #CONFIG LOAD#
     %args = loadcfg($cfgfile);
     
     #DELETE PREVIOUS FILES#
     my $ldifoutput=$args{"LDIFOUTPUT"};
     deleteLogFile();
     unlink($ldifoutput);

     #GENERATE CONTAINER PART FOR LDIF#
     addContainerToLdif(%args);

     #GENERATE LDIF FOR EACH USER#
     my $success = 0;
     foreach $username (@usernames) { 

      #GET THE SID FOR THE USER#
      $usersid=getSIDForUser($username);
      if (!$usersid){
       print "Failed";  
      }else{
       print "$usersid";
       #GENERATE ONE USER FOR LDIF#
       addUserToLdif($username,$usersid,%args);  
       $success = 1;
      }
      next;
     }

     #RUN LDAP MODIFY#
     if ($success == 1){ 
      runLdapModify(%args);
     }


    }

    sub usage()
    {
     my $usage="";

     $usage="usage: $0 [-h] | [-u users] | [-f file]"
     ."\n-h        : this (help) message"
     ."\n-u users  : list of user names separated by a space"
     ."\n\nexample: $0 -u user1 user2 user3";

     print STDERR $usage;
     exit;

    }

    sub addContainerToLdif {
     my (%args) = @_; 

     my $usercn = $args{"USERCN"};
     my $dn = $args{"DN"};
     my $ldifoutput=$args{"LDIFOUTPUT"};

     #CREATES THE CORRESPONDING LDIF FILE#
     #my $ldifcontainerinput = "dn: cn=$usercn,$dn\n"
     #. "changetype: add\n"
     #. "objectclass: container\n"
     #. "objectclass: top\n"
     #. "cn: $usercn\n";

         open OUTFILE, ">>$ldifoutput" or fatal("can't open $ldifoutput\n",1);
     print OUTFILE $ldifcontainerinput;
     close OUTFILE;
    }

    sub addUserToLdif {
     my ($username,$usersid,%args) = @_; 
     
     my $usercn = $args{"USERCN"};
     my $dn = $args{"DN"};
     my $ldifoutput=$args{"LDIFOUTPUT"}; 

     my $ldifuserinput = "dn: cn=$username,$dn\n"
     . "changetype: add\n"
     . "objectSID: $usersid\n"
     . "objectclass: userProxy\n"
     . "cn: $username\n";

         open OUTFILE, ">>$ldifoutput" or fatal("can't open $ldifoutput\n",1);
     print OUTFILE "\n$ldifuserinput";
     close OUTFILE;
    }


    sub runLdapModify {
     my (%args) = @_;
     
     my $adminname= $args{"ADMINNAME"};
     my $admindomain=$args{"ADMINDOMAIN"};
     my $adminpwd=$args{"ADMINPWD"};
     my $ldaphost=$args{"LDAPHOST"};
     my $ldapport=$args{"LDAPPORT"};
     my $ldifoutput=$args{"LDIFOUTPUT"};

     #MODIFY THE LDAP AND AD THE USER#
     print "\nRuns the ldifde command...";
     my $ldapmodify_cmd="ldifde -b $adminname $admindomain $adminpwd -s $ldaphost -t $ldapport -i -k -f $ldifoutput";

     writelogFile($ldapmodify_cmd);
     startRedirectError();
     $ldapmodify_output=`$ldapmodify_cmd`;
     stopRedirectError();
     writelogFile($ldapmodify_output);
     if ($ldapmodify_output =~ m/error/) {
      print "Failed";
      fatal("ldapmodify failed - please check $logfile and generated $ldifoutput and run again.",1);
     }else {
      print "Success";
     }
    }


    sub getSIDForUser {
     my ($username,$usersid) = @_;
     my $usersid = "";
     print "\nGets SID for user $username...";
     my $getsid_cmd="dsquery user forestroot -samid $username | dsget user -sid";

     writelogFile($getsid_cmd);
     startRedirectError(); 
     $getsid_output=`$getsid_cmd`;
     stopRedirectError();
     writelogFile($getsid_output);

     if ($getsid_output =~ m/(S[-\d+]+)/) {
      $usersid= $1;
     }

            return $usersid;

    }

    Ok, so it all works fine for our domain... here is where the wrench gets thrown into the mix.  We have another part of our organization that has their own domain, but now we find out that they too need access to Lawson.

    We already have a one way trust so that they can authenticate with things over here (ie: sharepoint).  Is there any way to setup their users from their domain in LDAP?  The only other solution I can think of is re-create all of their users in our domain and add them that way (pain in the you know what... not to mention all the extra CALs it would require).

    Thanks!

    Roger French
    Veteran Member
    Posts: 545
    Veteran Member
      Have you explored using the ldapbind? But remember it will only bind to one physical domain at a time.

      Here's another link to a kind of similar article you might want to read.

      https://www.lawsonguru.co...v/topic/Default.aspx

      DavidO
      Basic Member
      Posts: 5
      Basic Member

        Ok, so I could bind to the other domain's domain controller temporarily... create the user... and then switch the bind back to our domain retaining the other domain's user?

        Reading that post you suggested it sounds like they wanted to switch to a different domain controller in the same domain... I need to pull in users from an entirely different domain.

        We currently have a trust setup between the domains... shouldn't I be able to set it so that it queries both domains through our domain controller here?

        Roger French
        Veteran Member
        Posts: 545
        Veteran Member
          I don't think so. But try it out in ldapbind. I'd be interested to find out the results.
          DavidO
          Basic Member
          Posts: 5
          Basic Member
            If I do bind to a domain controller in a different domain... would that screw up what is in ldap already?
            Jimmy Chiu
            Veteran Member
            Posts: 641
            Veteran Member
              I don't know if this matches your situation.

              subdomain1.domain.com
              subdomain2.domain.com
              subdomain3.domain.com

              They are all trusted domain. In my case, lawson is on subdomain1.domain.com

              In order for lawson to authenticate users from subdomain2 and subdomain3. I have to recreate the users in subdomain1 and put them in a OU in subdomain1 (remote sites) for example.

              The 30 days password expiration probably needs to be turned off, you don't want them to start calling you every 30 days.
              DavidO
              Basic Member
              Posts: 5
              Basic Member
                Posted By Jimmy Chiu on 04/10/2009 08:11 PM
                I don't know if this matches your situation.

                subdomain1.domain.com
                subdomain2.domain.com
                subdomain3.domain.com

                They are all trusted domain. In my case, lawson is on subdomain1.domain.com

                In order for lawson to authenticate users from subdomain2 and subdomain3. I have to recreate the users in subdomain1 and put them in a OU in subdomain1 (remote sites) for example.

                The 30 days password expiration probably needs to be turned off, you don't want them to start calling you every 30 days.


                Yeah that's what my bosses wanted to avoid.  If we do it that way we have to purchase about 400 extra CALs.
                 

                Jimmy Chiu
                Veteran Member
                Posts: 641
                Veteran Member
                  I know your boss' pain. You can also avoid the LDAPBIND to DC for authentication and use ADAM/IBM to manage the password instead. That will eliminate the CAL issue... but users will have 2 passwords I guess.
                  Jimmy Chiu
                  Veteran Member
                  Posts: 641
                  Veteran Member
                    I have just recieved an email reply from Mark Deutsch, who is the director of technology services from Lawson.

                    "This is a new feature in LSF 9.0.1 ESP3. We have the ability to connect to multiple LDAP Providers now"

                    "With LSF901 ESP3, we support the ability to define the LDAP Provider attribute as a multi-list attribute, and have enabled the code to read and processes accordingly."

                    "He said this is a "Very high level explanation that should provide detail enough for the technical person asking"

                    I assume the codes are implemented and enabled in LSF 9.0.1 ESP3. I have yet to figure out how to configure multi-list LDAP attribute yet. But it's good because it enables ldapbind outside the domain forest from the email exchange I had. Just FYI.
                    You are not authorized to post a reply.