Using LDAP for Fun and Profit – Part Deux



By: gchilders

February 20, 2008 10:46 am

Reads: 207

Comments:2

Rating:0

Using LDAP for Fun and Profit – Part Deux

For the reader of this or my previous article (see Using LDAP for Fun and Profit), it may sound odd to describe using LDAP (Lightweight Directory Access Protocol) for “fun and profit”. We’re just having a little fun with that title. This second article is designed to be a “preemptive strike” to hopefully ward off all the anticipated snickers and “rolling of the eyes” which I might receive from certain quarters, such as: “Oh you, with your cute little Windows batch scripts, why don’t you just do something with a *real* operating system” (that is, Linux).

LDAP and Linux

Of course, as mentioned in the first article, LDAP was originally developed for the UNIX world, from its infancy at the University of Michigan. Thus it was simple enough to develop for the Linux platform, with the OpenLDAP Project, started in 1998 by Kurt Zeilenga.

Most server-class Linux distributions have OpenLDAP software pre-packaged in with the operating system installation media, or it can be freely downloaded from http://www.openldap.org.

Naturally, any time a great idea comes around, everyone wants to get in on the deal. Novell added LDAP services in its NetWare 5 operating system back in 1999. And Microsoft’s Active Directory, as well, is often described as an implementation of LDAP directory services for its Windows server operating system.

More and more applications, regardless of what OS platform on which they are developed, are using the simple yet powerful capabilities of LDAP to access and manage directory information. It is very common these days to see the makers of business software and operating systems touting their products to be “fully LDAP-compliant” in their marketing.

It is this compliance to the widely-accepted LDAP standards which makes it far easier for different applications, written by different software vendors, and which may run on entirely different OS platforms, to successfully communicate directory-based information with one another.

LDAP and Identity Management

Compliance to LDAP standards also makes it far easier (and even possible) to keep different and disparate directory services synchronized with one another. There are estimates that a large organization or corporation can have up to 200 or more different directories in use across the enterprise, from the simple “employee phone book” directories to the more comprehensive (and complex) HR and ERP application directories.

Increasingly, some newer applications are centralizing their directory information into general-purpose LDAP directories, thus reducing the headaches of multiple directories management. The high costs of multiple data entry into different directories and databases, with the higher risk of human error and having outdated or conflicting information, all make the need to have an automated identity management solution a “must-have”, rather than “nice-to-have” solution.

LDAP standardization of application directory communications provides a basic framework for achieving identity management across various (LDAP-compliant) directories.

If you know very much about Novell, you already realize that one of their primary software applications is named (quite simply) Novell Identity Manager. Now in version 3.5 (formerly called DirXML), this directory interchange software uses XML (Extensible Markup Language) to keep different directories synchronized, using Novell’s own eDirectory (formerly called Novell Directory Services or NDS) as the “Identity Vault” to centrally store and replicate directory information.

Novell’s Identity Manager (IDM) works with a host of different directories and databases, and not only those that are LDAP-compliant. IDM employs DirXML drivers to synchronize information between eDirectory, Active Directory, Lotus Notes, Microsoft Exchange, Novell GroupWise, LDAP directories, and Linux/Unix user management (and a host of others).

Understanding LDAP

Once you start working with Novell’s IDM product, you find that understanding LDAP is key to understanding how IDM works with directory information, and how it replicates it across different systems.

For example, if you are an old-timer to Novell’s NDS, you are used to seeing user information in Novell’s implementation of the X.500 hierarchical naming standard, such as:

JohnDoe.Sales.NewYork.ACME

or in its typeful format:

cn=JohnDoe.ou=Sales.ou=NewYork.o=ACME

This represents a “tree” structure such as:

ACME organization
NewYork organizational unit
Sales organizational unit
JohnDoe leaf object

The same user information, in LDAP format, is not too much different:

cn=JohnDoe,ou=Sales,ou=NewYork,o=ACME

In the LDAP format, the “dot” (.) delimiter is replaced by the comma (,); otherwise the format, and the hierarchical concepts which determine the format, remain the same. This is one reason why it makes so much sense to utilize LDAP when working work Novell eDirectory, and also why it’s usually not too difficult for eDirectory administrators to learn and grasp LDAP concepts and procedures.

LDAP Script Examples

Obviously, the whole purpose of creating executable scripts is to perform repetitive tasks very precisely and very quickly. That’s what computers do best. If we have a computer network that we manage with 1000 (or 100,000) user accounts, and we have to look up or change one attribute on every account, we certainly don’t want to have to manually perform this task on every single user account in some type of GUI utility.

In my first article, I put together some Windows batch scripts which used Novell’s ICE (Import-Conversion-Export) utility to manipulate eDirectory information stored on a NetWare server. But why limit ourselves to Windows batch scripts or to NetWare? After all, isn’t Novell the “Software for the Open Enterprise”™? So why not throw a little Linux into the mix, shall we?

I’d like to take the examples from my first article, and translate them to what we might use in the Linux realm. For the directory, I would still like to use eDirectory as the creme-de-la-creme directory (my biased opinion), but since it is a cross-platform directory, let’s use it on a Linux platform (SUSE 10, in this case). And instead of a Windows management PC, let’s also use Linux (also SUSE).

For the first example, we want to export user account information, with particular attributes, from eDirectory. We will select for our example the costCenter and costCenterDescription attributes (as before). In the Windows batch script, we issued this command:

C:\novell\consoleone\1.2\bin\ice.exe -S LDAP -s NWSERVER -p 389 -d cn=admin,o=main -w password -b "o=MAIN" -F objectClass=user -c sub -a costCenter,costCenterDescription -D LDIF -f C:\DATA\exportCC.ldif

This batch file uses ice.exe (Novell Import/Conversion/Export utility, called locally from c:\novell\consoleone\1.2\bin) to designate that the source handler is from an LDAP server (-S LDAP) named NWSERVER, and the destination handler is to an LDIF file (-D LDIF -f C:\DATA\exportCC.ldif). The TCP port (-p) is given, the authoritative user (-d) and password (-w) are given, the baseDN (-b), object type (-F), and search scope (-c) are given, as well as the particular attributes (-a) that we want to return.

If we’re still at a Windows workstation, with ConsoleOne (and thus ice.exe) installed, the only change to our script is the name of the server. So let’s run the same script against a Linux server which has eDirectory installed:

C:\novell\consoleone\1.2\bin\ice.exe -S LDAP -s SLES-1 -p 389 -d cn=admin,o=main -w password -b "o=MAIN" -F objectClass=user -c sub -a costCenter,costCenterDescription -D LDIF -f C:\DATA\exportCC.ldif

You will notice the command is exactly the same, except for the server name. If we entered in all of these parameters correctly at a command prompt (from a Windows client), we should see a result like this:

Total entries processed: 1054
Total entries failed: 0
End time: Friday, February 8, 2008
Total Time: 0:00:10.540
Time per entry: 00:00.010

The output LDIF file (exportCC.ldif), then, would look like this (only the first two records included here):


#This LDIF file was generated by Novell's ICE and the LDIF destination handler.
version: 1

dn: cn=admin,o=MAIN

dn: cn=User1,ou=NewYork,o=MAIN
changetype: add
costCenterDescription: SALES
costCenter: 444444

Note: These sample scripts use clear text passwords for LDAP authentication. For both NetWare and Linux servers running eDirectory, to enable clear text password binds, we must modify the LDAP Group object for the target server, on the General page, and uncheck the (default) “Require TLS for simple binds with password”.

Of course, if you want to use variables to substitute all of the script parameters, to make this script more re-usable, it might look like this:

:: Script to export objects and specific attributes using ICE to LDIF

:: Set required variables ## NOTE: attributes should be comma delimited
@echo off
set utility="C:\novell\consoleone\1.2\bin\ice.exe"
set server=SLES-1
set port=636
set sldap=-L
set cert=c:\certs\%server%.der
set authuser=cn=admin,o=main
set passwd=password
set baseDN="o=MAIN"
set objclass=user
set scope=sub
set attrs=costCenter,costCenterDescription
set datadir=C:\data
set outputfile=exportCC.ldif

:: Export objects from eDirectory using ICE
%utility% -S LDAP -s %server% -p %port% %sldap% %cert% -d %authuser% -w %passwd% -b %baseDN% -F objectClass=%objclass% -c %scope% -a %attrs% -D LDIF -f %datadir%\%outputfile%
pause

This version of the script makes it easy to change parameters, using set commands. You will notice that we also added SSL security this time by setting the “sldap” and “cert” variables. Of course, this pre-supposes that we exported the server certificate as “c:\certs\SLES-1.der”.

OK, that’s fine – so the ICE utility works the same whether the target LDAP (eDirectory) server is on the NetWare or the Linux platform.

Using Scripts on Linux

But what I really want to do is take the Windows workstation completely out of the picture. Will these scripts work when the client (the computer which is executing the commands) is a Linux computer?

Yes, they will. However, there are some notable differences between the Linux shell and the Windows command prompt. Let’s examine them here.

First off, we won’t be using the Win32 version of ICE (ice.exe). The ICE utility is installed by default on Linux when either eDirectory 8.7.3 or 8.8 is installed, or when ConsoleOne for Linux is installed. You can verify that you have access to ICE by typing “which ice” at the Linux console. For eDirectory 8.7.3, (or ConsoleOne) you will see this:

SUSE-1:~ # which ice
/usr/bin/ice

For eDirectory 8.8, you will see:

SUSE-2:~ # which ice
/opt/novell/eDirectory/bin/ice

These paths should be in the search path ($PATH) string, so this allows you to access the utility by merely typing “ice”. Note: Linux commands are case-sensitive, so “ice” and “ICE” refer to completely different files. Also, there is no need for file extensions, such as “.exe”.

So the comparable Linux command is this:

ice -S LDAP -s SLES-1 -p 389 -d cn=admin,o=main -w password -b "o=MAIN" -F objectClass=user -c sub -a costCenter,costCenterDescription -D LDIF -f ~/data/exportCC.ldif

Note: the full path to the ICE (ice) utility, /usr/bin/ice (or /opt/novell/eDirectory/bin/ice) could also be used. The destination for the output file here is using the “~” as shorthand for the current user’s home directory. Thus if I were logged in as jshmoe, the full path would typically be “/home/jshmoe/data/exportCC.ldif”.

Other than the Linux-specific differences, you’ll notice that the command syntax is otherwise exactly the same, demonstrating the cross-platform capabilities of both eDirectory (and its implementation of LDAP), as well as the ICE utility.

And just as we would do in batch files, if we wanted to use variables to substitute all of the script parameters, to make the Linux script more re-usable, it might look like this:

#!/bin/bash
# Script to export objects and specific attributes using ICE to LDIF

# Set required variables ## NOTE: attributes should be comma delimited
UTILITY=/usr/bin/ice
SERVER=SLES-1
PORT=636
SLDAP=-L
CERT=~/certs/$SERVER.der
AUTHUSER=cn=admin,o=main
PASSWD=password
BASEDN="o=MAIN"
OBJCLASS=user
SCOPE=sub
ATTRS=costCenter,costCenterDescription
DATADIR=~/data
OUTPUTFILE=exportCC.ldif

# Export objects from eDirectory using ICE
$UTILITY -S LDAP -s $SERVER -p $PORT $SLDAP $CERT -d $AUTHUSER -w $PASSWD -b $BASEDN -F objectClass=$OBJCLASS -c $SCOPE -a $ATTRS -D LDIF -f $DATADIR/$OUTPUTFILE

The “#!/bin/bash” comment at the beginning of the script denotes that this script is designed to run the Linux bash shell (unlike DOS, there are a variety of command shells available in Linux). In most Linux distributions, the “bash” executable is located in /bin/, and by default you have already a search path to that directory.

Notice the Linux-specific differences in this script: the “#” symbol is now used to comment out lines, and we don’t use a “set” command, just “UTILITY=” (etc.) to define the variables. The variable names do not have to be in uppercase, although it is a common practice. Again, keep in mind that Linux is case-sensitive, so the variable names “TEST”, “test”, and “Test” are all separate variables.

And instead of the batch file reference to the variables as (for example) “%variable%”, we use the Linux standard of “$VARIABLE”, with the single “$” symbol denoting the variable name. Also, we have to keep in mind that Linux uses forward slashes (“/”), instead of the DOS standard of backslashes (“\”) for file paths.

Finally, we should recognize that the ICE command parameters are also case-sensitive (note the difference for “-S” for source handler and “-s” for server); while the LDAP object names and attributes, such as “cn=admin,o=main” and “costCenter” are not case-sensitive.

An excellent Web resource for comparing/contrasting DOS batch and UNIX/Linux shell commands can be found here.

Just as we did before, we modified our command in this last example to use secure (encrypted) LDAP communications with the server by specifying the secure LDAP port 636, and by providing the path to the exported server certificate.

One more thing (if you are new to Linux scripts): unlike DOS/Win32 batch files, Linux script files are not executable until you specifically make them so. So if you’ve created a script call “myscript”, and saved it in the ~/bin directory (the bin directory under your home directory), then you would have to change its “mode” to make it executable by using this command:

chmod 755 bin/myscript

Once you do this, you can see that it is listed as executable by using this command:

ls -l ~/bin/myscript

This is similar to the “dir” command in DOS. This should yield this result:

-rwxr-xr-x 1 joeuser users 64 Feb 8 15:05

The “x” characters in the beginning let you know that the file is flagged as executable. If you need more information on the chmod utility, on Linux you can type “man chmod” to read the manual (or just Google “man chmod in a Web browser).

Executing the Script

Once we execute this script, (assuming we entered in all of the needed parameters correctly), we should see a result like this:

Total entries processed: 1054
Total entries failed: 0
End time: Fri, Feb 8 10:02:46 2008

Total Time: 0:00:10.540
Time per entry: 00:00.010

This is almost exactly the results we saw with our Win32 batch-file version of this script. The resulting output LDIF file (exportCC.ldif) would look – not almost, but exactly like the one from the batch script – like this (again, only the first two records included here):

#This LDIF file was generated by Novell's ICE and the LDIF destination handler.
version: 1

dn: cn=admin,o=MAIN

dn: cn=User1,ou=NewYork,o=MAIN
changetype: add
costCenterDescription: SALES
costCenter: 444444

This demonstrates the interoperability between the different platform versions of eDirectory and the ICE utility. So if you run an LDAP query against eDirectory on a NetWare server, from either a Windows or Linux PC using the ICE utility, and you run the exact same query against an eDirectory replica of the same partition on a Linux server, from either a Windows or a Linux PC using ICE, the results are exactly the same. This is important, because even though we must use slightly different syntax to get the information from different platforms, we definitely want the information to be exactly the same, regardless of how we got it.

There is a slight difference – and you already know this if you work with both Windows and Linux – with the way the Linux/Unix handles newlines in ASCII text files. Windows utilities, such as Notepad.exe, use two ASCII characters, (carriage return) and (linefeed, or newline) to denote a new line in a text file. Linux utilities merely use the newline .

This all goes back to the days of legacy computer printers, and the commands they needed to print the output, but the general result is that if you open any Linux-generated text file with a Windows utility such as Notepad, you see funny little boxes in the text where new lines should be. Most people who work with both OS platforms will use an alternate (more robust) Win32 text editing utility, such as TextPad (see http://www.textpad.com/download) to work with such files, so that they look the same on either platform.

A word on security: these test scripts are using an admin password, contained in clear text within the scripts. OK for the lab environment, maybe, but obviously not acceptable for the production environment. Typically, we might use these smaller scripts from within a larger script, and thus use other means than clear text to supply the password.

An alternate way of doing this, especially if we are merely doing LDAP searches which do not require special admin rights to eDirectory, is to use a service account with only enough rights to perform the desired actions. Another option, now that we are using the Linux version of ICE, is to use the (uppercase) “-W” (as opposed to the lowercase “-w”) option, which instead of reading the clear text password from the script, will pause and prompt the operator to supply the password securely at the console.

Sample Scripts on Linux

With all that said, let’s revisit some basic scripts, and see how they operate on a Linux platform. Here is an example of the Windows batch script (taken from the previous article) which imports user accounts from an LDIF file:

:: Script to import eDirectory users from LDIF
:: Set required variables
@echo off
set util="C:\novell\consoleone\1.2\bin\ice.exe"
set datadir=C:\data
set inputfile=importusers.ldif
set server=NWSERVER
set port=389
set authuser=cn=admin,o=MAIN
set /p passwd=Enter admin password: 

:: Import objects to eDirectory using ICE
%util% -S LDIF -f %datadir%\%inputfile% -D LDAP -s %server% -p %port% %sldap% %cert% -d %authuser% -w %passwd%
pause

When specified the parameters are filled in from the variables, the effective command that is given to the Win32 system is this:

"C:\novell\consoleone\1.2\bin\ice.exe" -S LDIF -f C:\data\importusers.ldif -D LDAP -s NWSERVER -p 389  -d cn=admin,o=MAIN -w password

OK, so how might we Linux-ize this script? We know the basics for Linux scripts: the typical “#!/bin/bash” at the beginning, the “#” symbol for comments, no use of “set” for variables, and the “$” symbol used to reference the variables, and forward slashes (“/”) for file paths.

So the Linux variation of the script might look like this:

#!/bin/bash
# Script to import eDirectory users from LDIF

# Set required variables
UTIL=/usr/bin/ice
DATADIR=~/data
INPUTFILE=importusers.ldif
SERVER=SLES-1
PORT=389
AUTHUSER=cn=admin,o=MAIN

# Import objects to eDirectory using ICE
$UTIL -S LDIF -f $DATADIR/$INPUTFILE -D LDAP -s $SERVER -p $PORT $SLDAP $CERT -d $AUTHUSER -W

When specified the parameters are filled in from the variables, the effective command that is given to the Linux system is this:

/usr/bin/ice -S LDIF -f /home/joeuser/data/importusers.ldif -D LDAP -s SLES-1 -p 389  -d cn=admin,o=MAIN -W

In the Win32 version, we used a simple “set /p” command to prompt the user for the password variable. But in the Linux version, we used the “-W” option, which also prompts for the password (but without printing it to the screen).

You will notice that both versions of the script skipped the setting of the $SLDAP (%sldap%) and $CERT (%cert%) variables, so those were omitted from the effective command. Since we used TCP port 389, this allowed us to transfer the information on the standard (unencrypted) LDAP channel.

If we had set the $PORT variable to 636 for secure LDAP, and specified the $SLDAP variable as “-L”, and provided the name of the server SSL certificate (as we did previously), we would merely change or add these lines to the script:

PORT=636
SLDAP=-L
CERT=~/certs/$SERVER.der

Again, this pre-supposes that we exported the server certificate as “~/certs/SLES-1.der”. Then the effective console command would be:

/usr/bin/ice -S LDIF -f /home/joeuser/data/importusers.ldif -D LDAP -s SLES-1 -p 636 -L /home/joeuser/certs/SLES-1.der -d cn=admin,o=MAIN -W

This does exactly the same job as the previous script, except that the network transfer of LDAP information will go over the secure LDAP port of 636, and it will be encrypted using the exported server SSL certificate.

Exactly as we would do for the Win32 version for this script, we could use an LDIF input file (importusers.ldif) that might look like this:

dn: cn=TestUser1,ou=Atlanta,o=MAIN
changetype: add
cn: TestUser1
company: ACME Corporation
description: Test User
fullName: Test User1
givenName: Test
groupMembership: cn=Atlanta Users,ou=Atlanta,o=MAIN
l: Atlanta
loginGraceRemaining: 3
loginGraceLimit: 5
objectClass: inetOrgPerson
objectClass: User
ou: Executive Management
passwordAllowChange: TRUE
passwordExpirationTime: 19920102000000Z
passwordExpirationInterval: 7776000
passwordMinimumLength: 6
passwordRequired: TRUE
passwordUniqueRequired: TRUE
sn: User1
title: Manager
userPassword: pa$$word

dn: cn=TestUser2,ou=Atlanta,o=MAIN
changetype: add
cn: TestUser2
company: ACME Corporation
description: Test User
fullName: Test User2
givenName: Test
groupMembership: cn=Atlanta Users,ou=Atlanta,o=MAIN
l: Atlanta
loginGraceRemaining: 3
loginGraceLimit: 5
objectClass: inetOrgPerson
objectClass: User
passwordAllowChange: TRUE
passwordExpirationTime: 19920102000000Z
passwordExpirationInterval: 7776000
passwordMinimumLength: 6
passwordRequired: TRUE
passwordUniqueRequired: TRUE
sn: User2
title: Manager
userPassword: pa$$word

As you can see, the information in the LDIF file sets some basic user information for the newly created users, including password requirements, and even setting the initial password for the user accounts. The “passwordExpirationTime” attribute is set so that the password is already expired, with only 3 grace logins (loginGraceRemaining) left, so that the users would be prompted to change their passwords upon login. The passwordExpirationInterval attribute sets the password expiration interval to 90 days (7776000 seconds).

The import thing to note is that it does not matter one bit whether you use the Win32 platform and syntax for the ICE commands, or the Linux platform and its syntax. The LDIF file syntax is determined by the LDAP protocol standards, and is exactly the same either way.

Changing Attributes on Existing Objects

A common administrative operation any network administrator may need to accomplish is to change particular attribute values on existing objects. We did this in the first article with this Win32 batch script:

:: Script to import eDirectory attributes from LDIF

:: Set required variables
@echo off
set util="C:\novell\consoleone\1.2\bin\ice.exe"
set datadir=C:\data
set inputfile=changeCC.ldif
set server=NWSERVER
set port=389
set authuser=cn=admin,o=MAIN
set /p passwd=Enter admin password: 

:: Import objects to eDirectory using ICE
%util% -S LDIF -f %datadir%\%inputfile% -D LDAP -s %server% -p %port% %sldap% %cert% -d %authuser% -w %passwd%
pause

This goes back to our first example, where we exported user accounts with the attributes of “costCenter” and “costCenterDescription”. So let’s say that HR has made a change for those users, and now they need to be modified with new values: the costCenter has changed to “444440″, and the costCenterDescription has changed to “Inside Sales”.

This import LDIF file is exactly the same as if we were using the Win32 version, such as this example:

version: 1

dn: cn=TestUser1,ou=Atlanta,o=MAIN
changetype: modify
replace: costCenterDescription
costCenterDescription: Inside Sales

dn: cn=TestUser1,ou=Atlanta,o=MAIN
changetype: modify
replace: costCenter
costCenter: 444440

dn: cn=TestUser2,ou=Atlanta,o=MAIN
changetype: modify
replace: costCenterDescription
costCenterDescription: Inside Sales

dn: cn=TestUser2,ou=Atlanta,o=MAIN
changetype: modify
replace: costCenter
costCenter: 444440

dn: cn=TestUser3,ou=Atlanta,o=MAIN
changetype: modify
replace: costCenterDescription
costCenterDescription: Inside Sales

dn: cn=TestUser3,ou=Atlanta,o=MAIN
changetype: modify
replace: costCenter
costCenter: 444440

Again, we’ll name it “changeCC.ldif”. This LDIF file is the input data file for the LDAP operation using ICE, to import (replace) the new values for the attributes costCenter and costCenterDescription for the selected entries.

And again, the script used to input this new data is almost exactly the same as the one we used above to import users. The only change here is that we are using a different input data file, which we just modified. So the Linux version of the script would look like:

#!/bin/bash
# Script to import eDirectory users from LDIF

# Set required variables
UTIL=/usr/bin/ice
DATADIR=~/data
INPUTFILE=changeCC.ldif
SERVER=SLES-1
PORT=389
AUTHUSER=cn=admin,o=MAIN

# Import objects to eDirectory using ICE
$UTIL -S LDIF -f $DATADIR/$INPUTFILE -D LDAP -s $SERVER -p $PORT $SLDAP $CERT -d $AUTHUSER -W

When specified the parameters are filled in from the variables, the effective command that is given to the Linux system is this:

/usr/bin/ice -S LDIF -f /home/joeuser/data/changeCC.ldif -D LDAP -s SLES-1 -p 389  -d cn=admin,o=MAIN -W

Just as in the Win32 script, we see the difference (between importing and modifying entries) is entirely in the LDIF data file which is fed into the ICE command. Since the changetype is now specified as “modify”, ICE will look for existing user accounts that match the specified “dn:” entries in the LDIF file. For each entry located, it will look for the “costCenter” and “costCenterDescription” attributes, replacing their values with the values specified in each entry (which, in our example, are the same for each entry).

Again, you will notice that for each attribute value change that we make (two changes per user) we have to make one entry in the LDIF file. This is why there are two separate entries (each beginning with “dn: “) for each user account in the example.

Conclusion

These simple examples of Linux shell scripts using LDAP and Novell’s ICE utility demonstrate the complete interoperability between the NetWare, Windows and Linux platforms, as far as LDAP (and Novell’s ICE) is concerned, and how to translate what you might have been doing with Win32 batch scripts into Linux shell scripts.

Once you’ve entered the wider world of Linux shell scripting, you soon find out it is by far more flexible and powerful than batch files could ever dream of being. So design your scripts with care, and diligently test them in your own lab environment. Then, after making this up-front investment in automating your repetitive tasks, you can then spend a little time planning what to do with all the administrative time you just saved!

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Tags:
Categories: Uncategorized

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

2 Comments

  1. By:sammydc

    Hi,

    I downloaded already several different sdk packages. cldap, ndslib, nwsdkc, and w32sdkc. I even installed the Novell Client and ConsoleOne. I cannot find the ice.exe utility. How do I get it installed on my machine?

    Please respond as soon as possible. Thanks.
    Sam

    • By:gchilders

      Download ConsoleOne. If you run ConsoleOne on Windows, ICE is in the consoleone\1.2\bin directory. If you run Linux, the ICE utility is installed by default on Linux when either eDirectory 8.7.3 or 8.8 is installed, or when ConsoleOne for Linux is installed. You can verify that you have access to ICE by typing “which ice” at the Linux console. For eDirectory 8.7.3, (or ConsoleOne) you will see this:

      SUSE-1:~ # which ice
      /usr/bin/ice

      For eDirectory 8.8, you will see:

      SUSE-2:~ # which ice
      /opt/novell/eDirectory/bin/ice

Comment