New at Download.novell.com: RADIUS Plug-in for iManager 2.7
↧
↧
Configuring iManager 2.7 to Use a Proxy Server
Problem
You want to configure your iManager to be able to access the Internet (for those plug-ins) through a proxy (such as squid or BorderManager).
Solution
1. Open imanager\bin\iManager.bat
2. Find the line that has ":DONE_VAR" in it.
3. Add the following just above that line. Obviously, replace "yourproxyipaddress" and "yourproxyport" appropriately.
set CATALINA_OPTS=%CATALINA_OPTS% -Dhttp.proxyHost=yourproxyipaddress set CATALINA_OPTS=%CATALINA_OPTS% -Dhttp.proxyPort=yourproxyport
4. Find the line that has "start %JAVA_EXE% -Xms256m -Xmx512m" at the start and edit it to have " %CATALINA_OPTS% " between the "%JAVA_EXE%" and the "-Xms256m". The completed line should look something like this:
start %JAVA_EXE% %CATALINA_OPTS% -Xms256m -Xmx512m -Xbootclasspath/a:%BPATH% -cp %CLASSPATH% -Djava.endorsed.dir=%EPATH% -Djava.library.path=%NATIVE_LIB_PATH%;%SWT_LIB_PATH% %DEBUG_PARAMS% %MAIN_CLASS% %1 %2 %3 %4 %5 %6 %7 %8 %9
5. Start your iManager and you'll see that it shows NPM's to download!
↧
How to Migrate iManager User Preferences to a Different iManager Installation
Problem
You need a quick way to transfer iManager user preferences to a different iManager installation.
Solution
The iManager user preferences are stored locally on each iManager installation. Each user who ever logged in on that iManager installation will get a directory with his preferences stored in various files. These directories can be found in tomcat\x\webapps\nps\WEB-INF\config (where x is the version number of the tomcat use for the iManager installation). It is enough to copy the preferences directory for a user with all the files contained in it to the same directory structure on the destination installation and the same preferences will apply there.
Note that you should only do this if you are using the same iManager version for both installations. Between different versions of iManager, the preferences are not guaranteed to be the same.
↧
Driver Cache Stats in the IDM 3.6 iManager Plugins
In the article, http://www.novell.com/communities/node/2206 I discussed some things about Novell Identity Manager engine cache files.
The Identity Manager engine, is the component that runs as an application within the eDirectory memory space (so it runs anywhere eDirectory can run, so very cross platform), and one of its most powerful features is the its event driven nature.
If an eDirectory instance has the Identity Manager engine installed, and loaded (which will require an Identity Manager Driver Set to be assigned to the server) then it will know what events the drivers in the driver set are looking for, and will cache those events that meet its criteria for processing for the driver. (The exception is if the driver is set to Disabled, (instead of Manual or Automatic on the drivers properties page, in which case the engine will ignore the events and not cache them for this driver).
The events are stored in a .TAO file, see the previous referenced article for lots more detail on the subject. The most common way to deal with this cache file has been to plain delete it, (which can be done via the filesystem, or just Disabling the driver, and when setting it back to either Manual or Automatic ticking the box that appears about not resyncing the application) or to look at its contents via the DXCMD toolkit.
With the release of the latest sets of Identity Manager plugins for iManager, they have been adding some really amazing functionality into the plugins.
I was able to grab a screen shot using the Novell Identity Manager 3.6 M1 Plugins for iManager 2.7 and it shows some neat stuff.
This it turns out is from a Linux/Unix Bidirectional driver connecting to an Solaris environment running NIS. We had submitted a couple of hundred delete jobs overnight, and you can see that 111 removes are left to go. But in the intervening time period while it was deleting the many hundreds of users, 237 more Modify events came in. (Some of this has to do with things that loop back when we delete them in NIS.)
One of our issues was that the Linux/Unix driver had to run a script after deleting a user to clean up the remote environment, and that was taking almost 20 minutes in many cases, due to one set of servers at a remote location.
The engine cache in Novell Identity Manager is a FIFO (First In, First Out) stack, so the events that piled up behind it, could not process until it got to be their turn.
As you can see, the new driver stats page, could show us, while the driver was running, what was going on inside the driver. In our case, we were getting complaints that password changes were not flowing, and a-yup, you can see why. They were probably stuck in the 237 Modify events waiting to process.
If you stop the driver, then you can use the iManager plugins to look at the actual events that make up the queue, much like you could via the DXCMD toolkit, just this time there is a User Interface on top of it, in a web browser.
Another interesting point that I alluded too in the article I mentioned above, is that the size of the TAO file is shown as two values.
The file itself, which if you looked in the filesystem, shows as 172,874 bytes. I.e. if you looked in SYS:_NEWTARE\*.TAO and you knew the object ID of the driver object, you would see a file of that size. (The locations are with your DIB set, so depending on your OS, and where you stored the DIB, would tell you where the TAO files are to be found).
Up till now, that is about all the info you had. In the previous article I discussed why the TAO file gets bigger with each event, but not smaller until all the events are gone. (Basically imagine how you would handle the file system event. Appending a new event to the end of the file is fast and easy. Deleting one in the middle and shifting everything back to use the cleared space is much slower and harder to do, so why bother?). Here is a nice example where we see first off that the plugin tells us the name of the TAO file, (no need to look it up in iMonitor, DSBROWSE, or other tool) tells us the file size in the file system, but adds a very useful line, Unprocessed size, of 69,762 bytes, so we now know that a good portion of that TAO file is empty. This is something we previously had little to no insight into.
To look at the contents of the cache requires that the driver be stopped, and this is apparently a limitation of the API. I really hope the engine team can modify the API some day to allow the plugins to look at the TAO file cache while the driver is running, (and hopefully delete or even better, modify, individual cached events) in some future release. If you try to look at a running drivers cache you get a 641 error via DXCMD, as well as via the iManager plugins, alas.
The use case for a modify of a cached event might be if you have a bunch of stuck events that you want to process but due to some bug in your rules, the exact event sent and sitting stuck in the cache is not going to work, but if you made a minor change, like say changing the case or spelling of an entitlement attribute, might now start to process. I.e. I have a driver that looks for an attribute acmeAddADAccount to go to a value, but for some reason my rule was setting the wrong value, and I stopped the driver after noticing. It would be really nice to dive into the TAO file, edit each event that has the wrong value, and let them process through.
Another nice feature the snapins reveal, that in principle you could get via the DXCMD tookit (by reading the first event and then the last event) is the age of the transactions in the cache file. It shows us the older and newest transaction. In our example, we can see that we are still processing events from 5AM, and there are events as new as 2:28PM. (I think I took the screen shot around 2:30PM).
This is very helpful in trying to understand how far behind your driver is, and whether you want to let it finish processing or stop it, clear the cache and try to get back going again.
Overall these new snapins are a great improvement, with lots of really useful new features. If you are not yet using them go out and get them, install iManager Mobile 2.7 on your workstation and try them in that isolated sandbox. Once you are happy, then you can roll them out to your production iManager instances. They technically are just milestone releases (the 3.6 build at least for now) but they seem to be pretty good so far, and now that I have gotten used to them, I find I cannot live without the new features.
↧
iManager / iMonitor certificate errors
Do you use iMonitor and iManager on the same server? Are you tired of the Security Alert dialog every time you switch between the 2? If so, then fix it!
This is iManager 2.7 on Windows, with eDirectory 8.7.3.9.
After a fresh installation of iManager, when you connect you will get this Security Alert.
Of the 3 items checked, there are 2 problems: there is no trust chain for the certificate, and the name in the certificate is different to the server you connected to. If you view the certificate…
… you can see that the certificate was issued by Temporary Certificate, for Temporary Certificate, which is clearly not the name of your server.
If you have iMonitor and iManager open on the same server, when you switch between them, you will get the security alert each time you change / refresh a page, as a different certificate is presented by each service.
This is how we set our Windows server to use the same certificate for iMonitor and iManager. The assumption is made that you have the trusted root installed into your browser, so that the certificate chain can be verified. I have created the certificate in ConsoleOne, but the concept should be similar using iManager.
Step 1: Create new KMO (certificate)
- Right click on the OU containing your server, click New, Object….
- In the New Object dialog, select NDSPKI:Key Material + click OK.
- In the Create Server Certificate (Key Material) dialog, select the appropriate server in the Server: dropdown.
- Enter Certificate name (e.g. KMO_HTTPS_76)
- Select the Custom radio button.
- Click Next.
- Select appropriate Certificate Authority (typically Organizational certificate authority.)
- Click Next.
- Select appropriate Key size (2048).
- Ensure that the SSL or TLS radio button is selected.
- Ensure that Set the Key Usage Extension to Critical is unchecked.
- Ensure that Allow Private Key to be Exported is checked.
- Click Next.
- Edit Subject name to show .CN=<name you use to connect> (e.g. .CN=server76 – Note leading period!)
- Set Validity period as appropriate.
- Click Next.
- Select appropriate trusted root certificate (typically Your organization’s certificate.)
- Click Next.
- Check that the parameters are correct, then click Finish.
The certificate is created in the OU holding the server (you might need to refresh to see it.)
Step 2: Set Http server to use new certificate
- Double-click Http Server - <server name>.
- Select the Other tab.
- Expand the httpKeyMaterialObject attribute.
- Double-click value (probably set to IP AG…..)
- Click the Browse button.
- Select the newly created certificate.
- Click OK.
- Restart NDS to pick up new certificate.
Connect to iMonitor + you should NOT get the Security Alert (assuming that you have the trusted root cert installed.)
Step 3: Export the new certificate
- Connect to iManager (you will get the Security Alert as iManager was installed with a ‘Temporary Certificate.)
- Click Yes to proceed.
- Login as an administrator.
- Click the Directory Administration role.
- Click the Modify Object role.
- Click the magnifying glass to open the browse box.
- Browse to, and select the new certificate.
- Click OK.
- Click the Certificates tab.
- Tick the box next to the new certificate.
- Click Export.
- In the Certificates drop down, select the new certificate (e.g. KMO_HTTPS_76.)
- Ensure that Export private key is selected.
- Enter an appropriate password.
- Confirm the password.
- Click Next.
- Click Save the Exported Certificate.
- In the File Download dialog, click Save.
- Browse to a suitable location and enter an appropriate name (e.g. KMO_HTTPS_76) a .pfx extension will be added.
Step 4: Convert new certificate to appropriate format
For this you will need OpenSSL (or similar.) You can download OpenSSL for windows from http://www.openssl.org/related/binaries.html (We have a previous version of iManager which runs on Apache, containing Openssl in \novell\apache\bin\)
Convert .pfx file to a .pem file.
- Open a cmd prompt and navigate to the location of the new certificate file.
- Enter \novell\Apache\bin\openssl.exe pkcs12 -in KMO_HTTPS_76.pfx -out KMO_HTTPS_76.pem.
- Enter the password used to export the certificate.
- Enter a password for the .pem file that you are creating. (This can be the same as when exporting with iManager.)
- Confirm password for the .pem file. (if you mistype the password a file will be generated, but you will get an error, so delete the file and run the command again.)
Convert the .pem file to a .p12 file.
- Enter E:\Certs>\novell\Apache\bin\openssl.exe pkcs12 -export -in KMO_HTTPS_76.pem -out KMO_HTTPS_76.p12 -name "iManager" (You can enter whatever name you want.)
- Enter the password used to convert the .pfx file to a .pem file.
- Enter a password for the .p12 file that you are creating. (Again, this can be the same.)
- Confirm password for the .p12 file. (if you mistype the password a file will be generated, but you will get an error, so delete the file and run the command again.)
Step 5: Configure iManager to use the new certificate.
- Copy the .p12 file to the tomcat certificate location on the iManager server. (C:\Program Files\Novell\Tomcat\conf\ssl\)
- Stop the Tomcat5 service.
- Edit the C:\Program Files\Novell\Tomcat\conf\server.xml file.
- Locate the section relating to the SSL Connector for the port you access iManager on (e.g. <!-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 -->.)
- You need to add a parameter for keystoreType, and amend the keystoreFile & keystorePass parameters.
- Add: keystoreType=PKCS12
- Amend: keystoreFile=C:\Program Files\Novell\Tomcat\conf\ssl\KMO_HTTPS_76.p12
- Amend: keystorePass=<password entered when generating the .p12 file> (e.g. keystorePass=password123)
Original entry
<!-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 --> <Connector acceptCount="100" clientAuth="false" debug="0" disableUploadTimeout="true" enableLookups="false" keystoreFile="conf/ssl/.keystore" keystorePass="changeit" maxSpareThreads="75" maxThreads="150" minSpareThreads="25" port="8443" scheme="https" secure="true" sslProtocol="TLS"/>Amended entry
<!-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 --> <Connector acceptCount="100" clientAuth="false" debug="0" disableUploadTimeout="true" enableLookups="false" keystoreType="PKCS12" keystoreFile="C:\Program Files\Novell\Tomcat\conf\ssl\KMO_HTTPS_57.p12" keystorePass="NEWPASSWORD" maxSpareThreads="75" maxThreads="150" minSpareThreads="25" port="8443" scheme="https" secure="true" sslProtocol="TLS"/> - Start the Tomcat5 service.
- Connect to iManager
You should NOT get the Security Alert now, and double clicking on the padlock will show the certificate you created, where the Issued to: name is that of the server.
You can now happily alternate between iMonitor and iManager and not get the annoying Security Alert each time you update a screen!
↧
↧
Replacing Open Enterprise Server 2 Linux Server Certificates
Utilizing eDirectory for LDAP authentication for various other systems saves administrators time and effort. Using SSL/TLS for LDAP authentication against eDirectory increases security and adds peace of mind to various system's administrators. The problem with this method is that, although Novell provides a 10 year Certificate of Authority (CA) for the eDirectory tree as a whole, individual server certificates are, by default, set to expire in 2 years. This can create a big mess for you and your connecting systems when they do.
In this article, we will replace our existing server certificates with newly created ones that are virtually the same, they just last until the CA itself expires. I'd attempted this several times using different avenues and had a lot of problems. Apache wouldn't load or the cert wasn't valid to the client using LDAPS. Just various run-of-the-mill, hair pulling frustrations.
The method I present here is sound and a lot simpler than what I'd tried in the past. All of it is done through iManager 2.7 and this is on OES 2 Linux.
- Create New Certificate
- Export Certificate
- SAS Service Object
- Replace Existing Certificate
- Verify LDAP Certificate
- Testing
- Conclusion
Create New Certificate
First of all, we need to create a new server certificate with the new expiration date.
Login to iManager and expand Novell Certificate Access. Click on Server Certificates. You will see a list of server certificates. At the top of the frame, click on New.
Ensure that the appropriate server appears in the field. Enter a name for the new certificate.
Select Custom and click Next
The next screen defaults to Organizational Authority. If we were creating this certificate with an external CA then we would select External. For this article, we are using our own internal CA. Click Next.
I've left the next screen default since we want a server certificate and don't want to change the encryption.
If you look in the middle, you will see the default Validity Period is 2 years, If you select Maximum it will set the certificate to expire when the CA expires, in our case, 10 years.
Click Next
I left the next screen to default.
The last screen gives you a summary of the selections your made. Notice the expiration date. If you need to make changes, click back until you get the option screen you need to change. When you are satisfied with your choices, click Finish and the certificate will be created.
Export Certificate
Go back to the Novell Certificate Access option and select Server Certificates. You will see your new certificate in the list. Place a check mark next to it and at the top of the frame select Export.
In the drop-down list at the top, select the certificate we just created. Ensure that the private key box is checked along with the “Include” box. Enter a password for the certificate and click Next.
Click Save the exported certificate link and save the file to your Desktop. (We'll need it again in a moment)
The file is saved as “cert.pfx” If there is a file with that name, it is not overwritten, but saved with the file name incremented, i.e., cert(2).pfx
SAS Service Object
By default, LDAP and Apache use “SSL CertificateDNS” as their certificate and by examining the properties of the SAS Service Object we'll verify this. The SAS Service Object allows you to define what certificates in eDirectory are synchronized with the certificate files in the file system.
Under Novell Certificate Access click on SAS Service Object.
Select the SAS Service Object for the server we're targeting.
Here, we see the eDirectory certificate and the paths to synchronize for the certificate and key files.
If you click on the certificate name you can modify the parameters – changing these will adverse affect Apache and the /etc/apache2/vhosts/vhost-ssl.conf will need to be modified to reflect the new paths.
Leave the current settings.
We just wanted to verify the name of the synchronized certificate.
Click Cancel.
Replace Existing Certificate
By default, LDAP and Apache use “SSL CertificateDNS” as their certificate. This is the one we'll be replacing. Now, iManager throws up some pretty intimidating messages with this process. Not too worry. When the certificate was originally created during the install process, there is a backup of this certificate created in /etc/ssl/servercerts/backup/, so we're safe.
Once again, select the Novell Certificate Access option and Server Certificates. This time Check the certificate “SSL CertificateDNS” and at the top of the frame select Replace.
This is the message I was speaking of earlier. Click OK.
Browse to the file Cert.pfx you saved on your Desktop. Enter the password you set to the certificate.
Click OK.
Since we're adding only one certificate, click Next.
Click Finish on the next frame.
The next screen will tell you of your Success.
Verifying LDAP Certificate
Now let's ensure that LDAP is pointing to the “SSL CertificateDNS” certificate.
Click the LDAP Options under LDAP
Click the LDAP Server Tab and then select the LDAP server.
Click Connections, at the top and verify the proper certificate is chosen. If not, then select the proper certificate and click Apply.
Click OK to close.
Let's look in the certificate directory to see if the new certificates are there.
Wait, those are the old files from April. The server itself will need to be rebooted. Upon reboot, eDirectory will synchronize the files from eDirectory. Let's check them now.
There they are. And backups were made of the previous files in the backup directory.
Testing
Open a browser and attempt HTTPS to the server. View the Certificate.
Notice the expiration date is now 2018.
We're done.
Conclusion
There are many parts of OES 2 and Linux in general that require configuration from the command line. This is a significant change to your OES 2 server that can be performed entirely from iManager. All we used the CDL for was file listing.
Enjoy.
↧
Manage Remote Linux Servers from iManager
This article discusses a way to manage a Linux server in the eDirectory tree from iManager. In NetWare, management and configuration of remote servers was done using NJCL. With the ceased support of NJCL in Linux, iManager plugins can now utilize owcimom to access remote files or manage services in a Linux server.
The article is divided into the following sections:
- Introduction
- Use of WBEM in iManager
- Implementing the MOF and the CIM provider
- Implementing the CIM client
Introduction
In NetWare, most iManager plugin developers use NJCL to configure and manage remote servers. NJCL provides file and directory access APIs in Java. When accessing iManager the eDirectory admin (or any user with sufficient rights) logs into the tree and hence has access to all volumes and files on all the servers that are in the tree. Hence writing information (configuration information that needs to be written) to a remote server using NJCL was a good solution. However NJCL is not being supported in Linux any more. Thus we need an alternative way to satisfy the same requirement in Linux servers. Three alternative approaches can be thought of to solve the problem of remote configuration and management in Linux servers:
- xplat libraries: These are C libraries which can be used for remote file system access. However, to use xplat libraries from java-based iManager successfully we need to write JNI wrappers.
- cifs:CIFS can be used as the alternative way. However, for that jcifs needs to be configured in each server for accessing a remote service in the server. This seems to be a cumbersome procedure
- CIMOM: All OES 2.0 servers run CIMOM by default. We can make use of CIM libraries to access the files or manage the server. This seems to be the most feasible way.
In the following sections iManager developers will get introduced to the convenient way of using CIM based services for remote management of Linux servers. It is assumed that the reader is familiar with iManager plugin development and the basics of writing a CIM provider. The reader is advised to go through the Supplementary section for better familiarity with CIM technologies.
Use of WBEM in iManager
We consider a case when the developer wants to read and write to a configuration file in a remote server from iManager. The steps to do this are:
Implementing the MOF and the CIM provider:
This section assumes that the reader is conversant with the basics of CIM and WBEM development.
- The MOF file: Figure 1 shows the description of the mof. We define a class, which will do the basic operations of read, write to a file. An instance of the file is identified by an id and a filename. The id is the key of the file access operation.
[Description ("This class represents a session with a file.")] class MyFileSession { [Description ("The ID of the current session"), Key ] uint32 ID; [Description ("The name of the file to access") ] String filename; [Description ("Write to the file. Returns 0 on success ") ] uint32 write ([in (true), out (false)] string to Write); [Description ("Read from the file.""Returns OK on success, EOF if end of file is reached ""while reading, and ERROR if an error occurred while reading. ""Length is the desired length requested by the client. ") , ValueMap {“0", "1", "2”}, Values {“OK", "EOF", "ERROR”}] uint32 read ([out (true), in (false)] string buf, [in (true), out (false)] uint32 length); };Figure 1: The MOF for file access provider.
- The CIM provider: We need to write a CIM provider for OpenWbem.The invokeMethod () of this provider will implement read and write functionalities for a file in the server. The method definitions of read () and write () are as per the MOF specified in Figure 1. I am not writing the code here as I assume that the links in the Supplemented section and some experience in CIM programming is enough to make it work. Also, OWCIMOM being an Open Source project, an existing provider often already exists to suffice your requirement.
Implementing the CIM Client
Remote read and write of any file can be done by directly calling the invokeMethod() of the provider from a CIM client interface defined in iManager. Given below are the steps to define the CIM client in iManager. The details regarding string manipulations and exception handling have been deliberately removed to stress on the basic functionality.
Authenticating to CIMOM: In Linux LUM is required for authentication. The authenticator calls into PAM. Authentication to CIMOM occurs when a user logs into an eDirectory tree and tries to access CIM for the first time. This will set up the Session. Given below are the steps of authenticating an iManager CIM client.
- Get the user credentials from the AuthenticationBroker object from iManager.
String [] auth = broker.getIdentity(); - Get the NDS Namespace from iManager.
ObjectEntry rootOE = (ObjectEntry)broker.
getAPIObject ("NDSNamespace");
NDSNamespace ns = (NDSNamespace) rootOE.getNamespace(); - Get the treeName
String tree = rootOE.getName(); - Get the user object and password credentials
ObjectEntry userOE = ns.getObjectEntry(rootOE, auth[0]);
String user = userOE.getName();
UserPrincipal principal = new UserPrincipal(user);
PasswordCredential cred = new PasswordCredential(auth[1]); - Finally, instantiate the cimom client.
MyCIMClient client = new MyCIMClient(ipAddress, principal, cred);
From here onwards iManager can call on the MyCIMClient’s read() or write() methods. These methods call invokemethods() on the CIM provider which we have defined in the earlier section. An implementation of the CIM client is given in the next section.
Defining a CIM client from iManager: Figure 2 is the skeleton program of a CIM client class in iManager.
public class MyCIMClient
{
private CIMObjectPath cop = null;
private CIMClient client;
private CIMObjectPath myCop;
private CIMClass myClass;
private String MY_CIM_CLASS = "MyFileSession";
public MyCIMClient (
String uriHostOrIP, //Host or IPAddres of the server to contact
UserPrincipal principal,
PasswordCredential credential){
CIMNameSpace cns = new CIMNameSpace (“https://”+uriHostOrIP+“: 5989”);
try{
client = new CIMClient(cns, principal, credential);
myCop = new CIMObjectPath (MY_CIM_CLASS);
myClass = client.getClass (myCop);
} catch (CIMException e){/*Ignoring Exception handling*/}
}private CIMObjectPath getMyPath(long sessionID){
CIMValue sessionIDValue = new CIMValue (new UnsignedInt32 (sessionID),
new CIMDataType(CIMDataType.UINT32));
CIMObjectPath myPath = new CIMObjectPath (MY_CIM_CLASS);
myPath.addKey ("ID", sessionIDValue);
return myPath;
}
private CIMObjectPath createMyInstance (String filename){
long sessionID = 0;
CIMInstance myInstance = myClass.newInstance ();
CIMValue filenameValue = new CIMValue (filename, new CIMDataType (CIMDataType.STRING));
try {
myInstance.setProperty ("filename", filenameValue);
} catch (CIMException e){/*Ignoring Exception Handling*/}
CIMValue sessionIDValue = new CIMValue (new UnsignedInt32 (sessionID), new CIMDataType (CIMDataType.UINT32));
try {
myInstance.setProperty ("ID", sessionIDValue);
} catch (CIMException e){/*Ignoring Exception Handling*/}
CIMObjectPath cop = new CIMObjectPath ();
cop = client.createInstance (myCop, myInstance);
}public void open(String filename){ //filename for the file with path to open
CIMObjectPath newCop = null;
try{
newCop = createMyInstance (filename);
} catch (CIMException e){/*Ignoring Exception Handling*/}
CIMProperty key = newCop.getKey("ID");
CIMValue sessionIDValue = key.getValue();
long sessionID = ((UnsignedInt32)sessionIDValue.getValue()).longValue();
cop = getMyPath(sessionID);
}public void close(){
try{
client.deleteInstance(cop);
} catch (CIMException e){}
}public String read(long length){
CIMArgument[] inArgs = new CIMArgument[1];
CIMValue lengthValue = new CIMValue(new UnsignedInt32(length), new
CIMDataType(CIMDataType.UINT32));
inArgs[0] = new CIMArgument("length", lengthValue);
CIMArgument[] outArgs = new CIMArgument[1];
String buf = null;
CIMValue bufValue = new CIMValue(buf, new
CIMDataType(CIMDataType.STRING));
outArgs[0] = new CIMArgument("buf", bufValue);
CIMValue returnVal = new CIMValue(new UnsignedInt32(1), new
CIMDataType(CIMDataType.UINT32));
try{
returnVal = client.invokeMethod( cop, //object path to instance
"read", // method to invoke
inArgs, //input array
outArgs); //output parameters
}catch (CIMException e){/*Ignoring Exception Handling*/}
String str= returnVal.toString();
return str;
}public void write(String toWrite){ /* Ignoring the details of this method*/}
Figure 2: The CIM client code
Supplementary Section
1. Developer_Primer_to_WBEM_and_CIM
2. An introduction to WBEM and OpenWBEM in SUSE Linux
↧
Command Line Migrate
license:
Free This tool is a perl script that will trigger an account to be migrated to a connected system.
This functionality is found in iManager in the DriverSet view, however, it is limited in functionality. In iManager you can select individual accounts to migrate or select by container. This is good if you want to do one or two or all users. What if, however, you have a list of 1,000 accounts spread across multiple containers? This tool addresses this problem while also making it easier to migrate 1 or 2 accounts, especially for those that live by the command line.
To run the script you must install perl (I use v5.10.0) and the perl-ldap module. The script is contained in the migrate.pl file. The migrate.conf file contains the ldap server parameters.
Syntax for migrate.conf:
$ldapServer = '192.168.1.1'; $ldapServerPort = '686'; $ldapUserDN = 'cn=brad,ou=People,o=novell'; $ldapUserPass = 'sneakyPassWord'; $ldapSearchBase = 'o=novell';
Syntax for migrate.pl:
# ./migrate.pl
<uid> = the search criteria to be executed. It can return a single entry or multiple entries.
<Driver> = the name of the driver to migrate the account(s) across. The value does not have to be the complete driver name, but is should be unique so as to distinguish it from other drivers.
Examples:
To migrate a single account, cn=brad,ou=people,o=novell across the driver, cn=edir,cn=DriverSet,ou=services,o=novell execute the command:
# ./migrate.pl cn=brad eDir
To migrate all accounts that start with "b" across the eDir driver execute the command:
# ./migrate.pl cn=b* eDir
To migrate a bulk list of accounts across the eDir driver execute a shell script containing the list of commands to execute:
./migrate.pl cn=adam eDir ./migrate.pl cn=brad eDir ./migrate.pl cn=carol eDir
The code is free to use. Feel free modify to meet your specific needs or send me any suggestions.
| Załącznik | Wielkość |
|---|---|
| migrate.tgz | 1.46 KB |
↧
Generate Full Name in Custom iManager Pages
The default iManager pages to create new users will auto-generate a full name for the user.
However, when creating custom pages in iManager using PluginStudio to edit or create users, the "Fullname" field won't get updated automatically.
With a little JavaScript/HTML knowledge this can be done quite easily. Here's how to proceed:
Locate the JSP that represents your "create user" page. If you created it with PluginStudio, it will be located in
[..]\tomcat\webapps\nps\portal\modules\custom\skins\default\devices\default\
The file name consists of the name you chose for the task and a time stamp. Something like "create_user_20081205_204600.jsp"
- if you have used PluginStudio to edit your task, there may be multiple copies with different time stamps.
Select the most recent one and create a backup copy.
Add a JavaScript function that generates the Fullname and put it into the existing <SCRIPT> .. </SCRIPT> section of your JSP.
The function could look like this
function generateFullname() { var form=document.forms[0]; var result = ''; if ( form._Given_Name != null ) { if ( form._Given_Name.value != '' ) result = form._Given_Name.value + ''; } if ( form._Surname != null ) result += form._Surname.value; if ( form._Full_Name != null ) form._Full_Name.value = result; }- Now you need to add calls to this function that get executed when the Given Name or Surname change.
Locate the HTML line that represents the Surname input field. Look for something like
<INPUT type='text' name="_Surname" ... >
and insert the function call, so that it looks like
<INPUT type='text' onkeyup='generateFullName();' name="_Surname" ... >
Locate the HTML line that represents the Given Name input field. Look for something like
<INPUT type='text' name="_Given_Name" ... >
and insert the function call, so that it looks like
<INPUT type='text' onkeyup='generateFullName();' name="_Given_Name" ... >
- Save the file and you're done. The effects should should show immediately.
↧
↧
Eliminate Excessive RBS Granted Rights for Password Sync Status Check
Check Password Synch Status as a Non Administrative Task.
Addressing Excessive RBSdefault rights.
This document assumes basic knowledge of iManager, eDirectory, RBS and RBS Custom task configuration.
While this document focuses on the specific “Check Password Synch Status” task, the concepts can be applied to any number of roles wherein the default RBS assigned rights are excessive.
BACKGROUND
Scenario: I wanted to setup a limited role that allowed members to check the password synchronization status of users across a set of IDM drivers. So I built a custom role containing only that task. During creation of that task, I noted (as in the screenshot) that there was a “Rights Advisory… Supervisory”
Intriguing as that was, I pressed on.
After creating the role, I had to associate a couple of different members, and I discovered another intriguing fact about RBS Role Member associations. First, I assign a user to have the right to do this task across the entire tree.
Here’s the member association:
And here is the resulting trusteeship …
So far, exactly as expected… a Role Object, part of my RBS container, is assigned as a trustee of [root] any member of that role will get the rights it assigns, which are…
Supervisor of the tree? Really? It takes supervisor rights to the assigned scope to view a user’s IDM Password Synch Status? (It doesn’t, but I don’t want to get ahead of myself.)
Let’s make another member association. This time I want to make a Group have the rights at the root.
I assumed that, as an associated member of the role, it would get the benefits of the trusteeship already established for the individual user in the previous step. What is it they say about not assuming?
Apparently, eDirectory does not calculate inherited rights from an RBS role, through a Group, to a User. So instead of using the existing RBS role object trustee, the RBS system establishes additional trusteeships for Groups that are members. And, yes, the Group is assigned the Supervisor right to the specified scope… in my case, to the [root].
PROBLEM:
So what’s the problem? Using iManager, the user is still limited to only checking password statuses, right? Sure. But, if the user accesses the tree via means other than iManager, they have Supervisor rights to the tree. ConsoleOne, Novell Client, NWAdmin32…
FIX AND RECOMMENDATIONS:
There is a fix, and short of reprogramming the NPM or creating a custom NPM, there are a couple of recommendations on how to approach the use of roles for which you have to modify the default rights.
The picture that follows demonstrates the specific rights required to allow a user to Check DIRXML Password Synch Status.
WHERE these rights are granted apparently matters, though I have not investigated…Since the right to use the DirXML-AccessCheckObjectPassword implies sending a document through the drivers, these rights must be assigned at a level that will inherit to the Driver Set, as well as to all the users on which you want this role to be able to verify password synch status.
Bottom line: It is possible to modify the default rights assigned by any RBS Role, to eliminate security risks. What ACL modifications and where to place them in your tree is up to you to find out for each specific case.
SECONDARY ISSUE:
All is well, right? Not so fast. What happens when you add another member to the role, at ANY level of the tree? You will find that ALL members have the ACL’s reset to the default of Supervisor, at the level/scope which they are defined.
No matter how much careful work you put into setting the correct level of rights for this role, throughout your tree, when you add a single new member association it will all be undone.
RECOMMENDATIONS:
Again, short of reprogramming default NPM’s, or copying and creating custom NPM’s so that they do NOT assign overbroad rights, you need to manage the problems presented with as little effort as possible. There are two ways to minimize the problem in this case:
- Assign/Associate only “Groups” to your custom role for Password Sync Status. This gives you the flexibility to add new people to the roles without causing the “re-set” of ACL’s on the scoped OU’s.
- If you require varying groups to have varying rights at different levels of the tree, assign/associate those Groups to the role at their respective scopes.
- AFTER assigning all members to the role, go to each scope OU level where you assigned a group to use this role, and modify the assigned rights as depicted earlier.
- Strictly manage/control who adds member associations to roles that assign excessive rights. You must be aware when someone makes a change that is going to suddenly assign supervisor rights to multiple people in the tree.
- Adopt a method for managing the rights whenever a new user or group is added as an RBS Role member.
- Export the ACL’s for those OU’s and create an LDIF file so that future re-establishment of these rights is easier and less “manual.”
- Then, when you add new group assignments to new scopes It should be a simple task to cut/paste a section for any new “role” or “group” ACL that gets added as a result of new Member Associations to new scopes.
- After modifying the LDIF file to contain a section for the newly associated member(s), reimport it to quickly re-establish the correct rights.
This method is practical if you have a role with multiple scopes, multiple individual user memberships… in other words, a lot of ACL’s that will be modified when a new member is added.
If you have a single scope, manually modifying the attributes on group and role trustees may be manageable.
That’s all well and good if you are NEVER going to add another member association to a role. Since every NEW member association will reset the ACL’s for all existing members, and since it is impractical to think your role will be setup correctly and finally on day one, it makes sense that you need to manage the ACL’s after new members are added.
Demonstrating the techniques for establishing such an LDIF file are beyond the scope of this document.
↧
Nested Groups Creation and Association of Static Group to Nested Group using iManager 2.7 SP2
Problem:
I need to create a nested Group in eDirectory 8.8.2 FTF1 or later, using the plugins available with iManager 2.7 SP1 or later and associate a static group to it.
Note: The Nested Groups feature is available from eDirectory 8.8.2 onwards. The static group needs to be converted to a nested group, in order to associate a static group to nested group using the object class nestedGroupAux.
Solution:
- Log in to iManager 2.7 SP1 or later with Administrator credentials.
- Select Groups from the leftmost panel and create a static Group SG1:
- Select Directory Administration ->Modify object -> Browse SG1.novell and go to "Other" tab-> Select Objectclass
- Edit Objectclass attribute -> Add nestedGroupAux.
- Apply these changes and click OK.
- Select Groups from the leftmost panel and create a Nested Group NG1 by checking the option of Nested Group and click OK
- Select Groups -> Modify group -> NG1.novell
![]()
Figure 5: Showing the selection Nested Group in order to associate static group to it.
- Select -> Nested tab -> Group Member tab -> Browse for static group SG1 and apply the changes and click on OK.
![]()
Figure 6: Showing the association of static group SG1 (converted to a nested group) to Nested group NG1.
With this the static group (which is now converted to nested group) is made as the member of the static group using iManager.
- Select Groups -> Modify group -> SG1.novell
- Select -> Nested tab -> Group Membership tab
In the above screen shot -> Static group's membership information is shown as NG1.novell
Note: Nested tab provides only the Group members information and the Members tab provides all the user members information.The below screen shot shows the usage of Members tab, to view the user members of the group.
Verification:
↧
Active Directory Driver Error Messages - Part 1
Novell Identity Manager is a complex product. One of the factors that affects the level of complexity is that beyond the core engine functionality, you need to learn the vargaries of all the various connected systems.
With dozens of available drivers, and for several of those drivers connecting to several possible systems (LDAP, JDBC drivers for example) the possible error states are numerous, and to be honest, not really documented. Part of the problem is that many of the error messages really are self explanatory, as the error returned is pretty clear. Makes it kind of hard to get any motivation to document that kind of thing! But also because there are so many possible error states, it becomes almost an impossible task.
When I start with a new driver now, what I do is snap a quick copy of any error I run into, write a short note about what caused it, how I fixed it, and forget about it.
Then when I have some time I write it up as an article, that you are about to read.
For the JDBC driver, which can connect to many different databases (MS SQL 2000, 2005, 2008, Oracle v8, v9, v10, Postgress, MySQL, DB2, and possibly more) there are even more error codes than you can imagine. I have a series on the errors we saw while developing a driver to connect to Oracle 9.
You can read that series at:
- Error Codes of the Novell Identity Manager Driver for JDBC: Part 1 of 4
- Error Codes of the Novell Identity Manager Driver for JDBC: Part 2 of 4
- Error Codes of the Novell Identity Manager Driver for JDBC: Part 3 of 4
- Error Codes of the Novell Identity Manager Driver for JDBC: Part 4 of 4
I have enough error codes collected for part 5, I just have to get around to writing it!
In this article, I wanted to share some of the error codes I ran into with Active Directory. My hope is that by posting the text of the error messages (as I saw them in Dstrace, which if you are not familiar with, the definitive guide to reading Dstrace for Identity Manager is at: Capturing and Reading Novell Identity Manager Traces) someone else who runs into one of those specific errors, will be able to paste in the error message in Google, and find my article explaining what I did wrong, and how I fixed it.
I would love to see other people do the same thing for other drivers! So here is my challenge to you, dear reader. If you like my articles, then my fee for service is do the same thing I have been doing, collecting error codes! As you develop a new driver (even one you are very familair with, like the Active Directory driver here) and you see an error message in DSTrace, be sure to copy the message, describe the circumstances, and please post them for every one to benefit from! Believe me, if you run into one of this odd errors, Google it, and find an exact response, you will know exactly why it is worthwhile to do this sort of thing!
This time around, I was approaching an Active Directory driver from a slightly different perspective. This time, we had three domains to synchronize and wanted to only develop one driver, to share across all three. We had two different approaches possible, each with pros and cons. The first approach would be develop to one domain, then export to a configuration file. Import it as a second (and eventually a third) driver and just change the configuration information. That would probably work, but it has one major weakness. If you realize after you have built the second and third driver that there is a design flaw, or a minor change, then you have to remember to back and change the exact same thing in the other two drivers. This takes a strong level of self control to actually remember to document what you did, exactly, so you can reproduce it twice more.
The second approach, which we took, was to develop the driver once, but to make all the rules used in each part of the fishbone diagram, be linked from a Library object. (For more information on what each policy and rule does in that flow, you should read this truly excellent review of the topic by David Gersic ). Its a three parter, but well worth the read, and it makes a great reference! You will learn something from it! I know I did! A Guided Tour of Novell Identity Manager - Part 1,
A Guided Tour of Novell Identity Manager - Part 2, A Guided Tour of Novell Identity Manager - Part 3 )
We moved all the rules we were using into a Library object at the root of the driverset, and then when we export the configuration, it exports the links to the rules, and when we reimport it to build the second and third drivers, it uses the links instead of new copies of the rules.
This way, when we make a change in a single location, it affects all three drivers. Now the major downside is that you really need to test that the change you made works in all three domains. This is not always clear cut. However, we felt the trade off was worth it. Of course, if you decide to add a new policy object, or modify the linkage order, you would have to redo it in the other two drivers as well.
In order to manage the differences between the three drivers we end up with a number of Global Configuration Variables. These are great, and my favorite things! Use them, they are awesome!
Finally, on to the errors:
Invalid Credentails, Active directory side:
<nds dtdversion="3.5" ndsversion="8.x">
<input>
<status level="fatal" type="driver-general">
<message>unable to authenticate to Active Directory</message>
<ldap-err ldap-rc="49" ldap-rc-name="LDAP_INVALID_CREDENTIALS">
<client-err ldap-rc="49" ldap-rc-name="LDAP_INVALID_CREDENTIALS">Invalid Credentials</client-err>
<server-err>8009030C: LdapErr: DSID-0C0904D1, comment: AcceptSecurityContext error, data 52e, v1771</server-err>
<server-err-ex win32-rc="-2146893044"/>
</ldap-err>
</status>
<init-params event-id="write state">
<publisher-state>
<cookie>INITIALIZE_COOKIE</cookie>
</publisher-state>
</init-params>
</input>
</nds>
This error is pretty clear and straightforward. We got an LDAP 49 error, with a sub code of 52e. Conviently, I had already written an article listing out all the sub codes for error 49, as I can never remember them all. Look at: Sub-Error Codes for LDAP Error 49
LDAP Error 49 is basically failure to authenticate successfully, and then subcode 52e means bad password, about the same as eDirectory's 669 error. You might see other codes like 525 which is the equivalent of eDirectory's 601 error, no such object. We have one of those later on in this article.
What happened here was I copied driver from one instance to another, forgot to set the password for the user in the new domain so of course got a bad password error. Passwords are stored encrypted in the driver object, much the same as named passwords are stored, (actually it is probably the other way around, that named passwords, an addition in Identity Manager 3.0, used the same existing mechanism for storing passwords as was already in use for the application, driver object, and remote passwords.
In this case, I needed to set the Application password in iManager on the Driver properties page.
672 Error, insufficient access, eDirectory side:
[04/03/09 15:34:17.631]:EMEA-AD PT:
<nds dtdversion="2.2">
<source>
<product version="3.6.0.4294">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<add class-name="Organizational Unit" dest-dn="Acme\Structure\corp\acme\emea\Germany" event-id="EMEA-AD##1206d78a891##0" src-dn="OU=Germany,DC=emea,DC=acme,DC=corp">
<association>8c0fc615153e924ab13b0fb7fa8fe3c6</association>
<add-attr attr-name="OU">
<value type="string">Germany</value>
</add-attr>
<add-attr attr-name="Object Class">
<value type="string">DirXML-ApplicationAttrs</value>
</add-attr>
<add-attr attr-name="DirXML-ADContext">
<value type="string">OU=Germany,DC=emea,DC=acme,DC=corp</value>
</add-attr>
<operation-data unmatched-src-dn="Germany"/>
</add>
</input>
</nds>
[04/03/09 15:34:17.633]:EMEA-AD PT:Filtering out notification-only attributes.
[04/03/09 15:34:17.633]:EMEA-AD PT:Pumping XDS to eDirectory.
[04/03/09 15:34:17.633]:EMEA-AD PT:Performing operation add for Acme\Structure\corp\acme\emea\Germany.
[04/03/09 15:34:17.634]:EMEA-AD PT:Adding entry Acme\Structure\corp\acme\emea\Germany.
[04/03/09 15:34:17.634]:EMEA-AD PT:Creating RDN Germany in context Acme\Structure\corp\acme\emea.
[04/03/09 15:34:17.642]:EMEA-AD PT:
DirXML Log Event -------------------
Driver: \ACME-LAB-IDV\Acme\Drivers\IDM\EMEA-AD
Channel: Publisher
Object: OU=Germany,DC=emea,DC=acme,DC=corp (Acme\Structure\corp\acme\emea\Germany)
Status: Error
Message: Code(-9010) An exception occurred: novell.jclient.JCException: createEntry -672 ERR_NO_ACCESS
This error occured once I got the driver up and running. Then the first thing I wanted to test was to make an object in Active Directory (an Organizational Unit in this case) and see if it would synchronize to eDirectory.
You can see that all looks good, but as it gets sent to eDirectory to write, we get a 672 error. 672 errors have about a dozen possible causes, and often the simplest is the explanation, insufficient access. In this case, I forgot to do Security Equivalences when I imported the driver! No access because the driver object has no rights to write to eDirectory.
You can fix this in iManager or Designer, via the Security Equals options. In iManager it is on the Driver properties page, and there is a Security Equals tab. In Designer, because this is a live operation, as opposed to an offline operation (you have to make changes in eDirectory for it to have any meaning, and it is not something that can be deployed) it is a separate menu option, right click the driver connection line, select Live, and at the bottom you can Manager Driver Security.
I personally am lazy and instead go straight to the object in ConsoleOne, right click to get the Properties, then on the Other tab, I add an attribute Security Equals and pick the object we use that has enough rights. During devlopment I usually use an Admin object because I am lazy. Once we roll out to production, I make an object, exclude it from synchronization (which sets a DirXML-Association value of 0) and give it sufficient rights, only to the desired containers.
This error was all about not having enough rights to write to eDirectory. There is another version of the same basic error, where the driver cannot read the attribute it wants. This one is less obvious, so often it is easier to spot the 672 error in trace first.
10:50:48 DBA19BA0 Drvrs: Active Directory ST:Driver object has insufficient rights to read \ACME-LAB-IDV\Acme\Users\Testing#DirXML-ADContext.
You can see that it was trying to read DirXML-ADContent on a user named Testing, and failed with insufficient rights. Same solution as above fixes this, set Security Equals on the driver object.
LDAP Referral error:
<nds dtdversion="1.1" ndsversion="8.7"> <source> <product asn1id="" build="20080229_143300" instance="\ACME-LAB-IDV\Acme\Drivers\IDM\Active Directory" version="3.5.3">AD</product> <contact>Novell, Inc.</contact> </source> <output> <status event-id="0" level="error" type="driver-general"> <message>Error getting next page of search results</message> <ldap-err ldap-rc="10" ldap-rc-name="LDAP_REFERRAL"> <server-err>0000202B: RefErr: DSID-03100768, data 0, 1 access points ref 1: 'acme.com'</server-err> <server-err-ex win32-rc="8235"/> </ldap-err> </status> </output> </nds>
This error should not normally happen, which makes it even more fun, since it did! When I was first starting in on this project, there were a number of people involved, and I did not fully understand what every server was doing. In particular, I did not know that the names of the Active Directory domain I was connecting too was different than I was expecting. Thus I was looking for objects to match, in the wrong base DN in Active Directory. I thought it was acme.com and in reality the domain was named acme.corp. Thus on the query, it would fail, with an LDAP referral error, since it could not figure out where to refer my query to complete it.
As you can see, this should never really happen in the real world, since who makes typos after all? Good to know what it would look like if you did though
!
Operation Vetoed by Create Policy (No UP):
19:00:00 DBA19BA0 Drvrs: Active Directory ST:Applying policy: [Acme] sub-AD-Creation.
19:27:54 DBA19BA0 Drvrs: Active Directory ST: Applying to add #1.
19:00:00 DBA19BA0 Drvrs: Active Directory ST: Evaluating selection criteria for rule 'Veto if nspmDistributionPassword is not available'.
19:00:00 DBA19BA0 Drvrs: Active Directory ST: (if-class-name equal "User") = TRUE.
19:00:02 DBA19BA0 Drvrs: Active Directory ST: (if-global-variable 'enable-password-subscribe' equal "true") = TRUE.
19:00:00 DBA19BA0 Drvrs: Active Directory ST: Rule selected.
19:00:31 DBA19BA0 Drvrs: Active Directory ST: Applying rule 'Veto if nspmDistributionPassword is not available'.
19:01:40 DBA19BA0 Drvrs: Active Directory ST: Action: do-veto-if-op-attr-not-available("nspmDistributionPassword").
19:00:00 DBA19BA0 Drvrs: Active Directory ST:Policy returned:
19:00:00 DBA19BA0 Drvrs: Active Directory ST:
<nds dtdversion="3.5" ndsversion="8.x">
<source>
<product version="3.6.0.4294">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input/>
</nds>
19:07:09 DBA19BA0 Drvrs: Active Directory ST:Processing returned document.
19:00:00 DBA19BA0 Drvrs: Active Directory ST:Processing operation <status> for .
19:00:01 DBA19BA0 Drvrs: Active Directory ST:
DirXML Log Event -------------------
Driver: \ACME-LAB-IDV\Acme\Drivers\IDM\Active Directory
Channel: Subscriber
Object: \ACME-LAB-IDV\Acme\Users\Testing
Status: Warning
Message: Code(-8017) Operation vetoed by object creation policy.
Error code 8017 is not really an error in the usual sense, as you can see the Status level is actually just Warning. Usually these cases are because the object being processed is missing some attribute. Actually it happens when ever a Veto occurs in the Create or Placement policies. There are lots of cases where this is normal.
On the Publisher channel, this is very common because the User in Active Directory is missing a mandatory attribute that eDirectory schema requires. Usually Surname in the case of User objects. That is because eDirectory will not let you make a user without specifying a Surname value. It is built into base schema, and while technically you might be able to change base schema with a properly constructed LDIF file, it is probably inadvisable.
An amusing case where this becomes an issue is with some Indonesian folk who apparently only have first names, and do not have Surnames at all. When you need to create User objects for them, you need to make a decision of what you will put in Surname, usually I just throw my hands in the air and just call their first name their last name. I am not sure what better way there is to handle this. I have seen putting the first letter of their first name in as their Surname but I am not sure that is better.
On the Subscriber channel, sending events into Active Directory there are two mandatory attributes (well one is mandated by Active Directory (Full Name), the other because it makes sense (a password)). Active Directory allows users to be created with a Given Name or Surname, but needs to have a value for Full Name. The default driver configuration requires that there be a nspmDistributionPassword as well. The reason for this one is that Active Directory will not let you make a user that is active without a password, unless you set the bit to allow that. In the usual case, if you create a user without a password they are disabled. Which is probably not what you want.
This one had me scratching my head, since I knew I had set a password on the User. But again as I learned on this project, I was walking into a half configured world, so I decided to see if Universal Password was even enabled in this tree.
Lo and behold there was no Password Policy defined nor assigned to any users in the tree. This was easy enough to fix. In iManager, in the Passwords section, I was able to define a Password Policy that matched the production policy, and assign it to the entire tree. Once that was done, I had to set the password again, to populate Universal Password. (I suppose I could have done an LDAP bind which under eDirectory 8.8 at least, should see that the policy says to use Universal Passwords, and although I authenticated with the value from the RSA key pair (aka NDS password) I should set it in Universal Password as well. Client32 does this as well on logins, if you have NMAS installed and a reasonably new version.
Depending on your application being connected too, you may have other requirements on an object before it can be sent to the connected system, or sent back to eDirectory. An example might be a flag, like acmeAllowADAccount set to true. This would allow you to control which accounts get sent to the connected system, as they would require a flag attribute (that you make up, or reuse some existing attribute, perhaps group membership) before being allowed past the Create rule.
Hopefully this beginning has whetted your appetite for more error codes, so stay tuned for part two of this series, where we have lots more error codes coming. We shall have to see how many more I can track down to write about.
As always, I encourage everyone to start doing this themselves. As you start working on a driver be sure to copy and paste any errors you run into, so that everyone can share from what you learned along the way.
↧
iManager Workstation 2.7: How to Configure and Troubleshoot a Local Copy of iManager on Windows
Novell has taken some lumps about management tools over the years, and with iManager they may or may not be warranted, that is up to the individual user. However, anyone who has struggled with iManager and adding plug-ins can relate to how frustrating it can be to correct issues once they occur. Locating information for configuring and yes, fixing, iManager can be frustrating to say the least.
Much of this information is available in online documentation, TIDs, and tech tips. Since I recently found a solution to one of the issues that has been plaguing me, I thought it would be “cool” to submit some of the tips and tweaks I’ve come across in one place.
First off, I only use iManager Workstation because 1) it does not require any server-side configuration, and 2) it runs much faster.
Configuring iManager Workstation
- Download the full version of iManager Workstation (currently 2.7) from http://download.novell.com
- Extract the files to the desired location, typically c:\novell\imanager
- Create a desktop shortcut for C:\Novell\imanager\bin\imanager.bat
- Optional: configure iManager for unrestricted access should you not wish to use Role Based Services, or for “troubleshooting purposes” as TID 10095953 describes (http://support.novell.com/docs/Tids/Solutions/10095953.html)
- Edit C:\Novell\imanager\tomcat\webapps\nps\WEB-INF\config.xml
- Insert the following at the bottom of the file BEFORE the </config> ending tag:
<setting> <name><![CDATA[RBS.forceUnrestricted]]></name> <value><![CDATA[true]]></value> </setting>
- Start iManager and authenticate with admin-equivalent rights
- If your internet access is behind a proxy server, navigate to the Configure page, select iManager Server-->Configure iManager from the navigation pane, then select the Plug-in Download tab. Check “Enable Proxy” and enter requisite information.Note: as of the time of writing, iManager Workstation 2.7 does not include the proxy information. Download and manually add iManager 2.7 SP2 for that functionality.
Another method is to add the proxy information to the iManager.bat file, see Preycor’s Technical Tip Configuring iManager 2.7 to Use a Proxy Server (http://www.novell.com/communities/node/4530/configuring-imanager-27-use-a-proxy-server)
- Navigate to Plug-in Installation-->Available Novell Plug-in Modules, select and install the desired plug-ins.
Troubleshooting
We geeks always want to try to figure stuff out on our own, but sometimes it pays to check the documentation!
Problem: One of the more exasperating issues we have come across with iManager Workstation is that after unzipping the iManager Workstation files to the local drive and adding one or more plug-ins, iManager would stop showing additional windows such as the Object Selector window to browse for an object.
After much frustration attempting to get a working configuration of iManager (2.7) with plug-ins for Identity Manager 3.6, and no luck finding any help on the interwebz, I finally looked in the online documentation, and there it was in the Troubleshooting section. Whodathunk!!!
The following is from the Troubleshooting section of the iManager 2.7 Administration Guide:
http://www.novell.com/documentation/imanager27/imanager_admin_272/index.html?page=/documentation/imanager27/imanager_admin_272/data/bouqsqh.html
~begin quotation~
8.15 iManager Workstation Does Not Display Information
iManager workstation might not display error messages, and load pages such as Tree View, Object Browse, Create Objects, and page after clicking the Refresh button. This happens when the XULRunner browsercache contains old data of the previous build of iManager 2.7 workstation.
Work around: You must manually clear the data from browser cache.
For Windows:
Exit iManager.
Browse for C:\Users\\AppData\Edit: doc shows path for Vista...for XP look here: C:\Documents and Settings\<username>\Application Data\Mozilla\eclipse\Cache
Delete all the data from the Cache directory.
Restart iManager.
For Linux:
Exit iManager.
Browse for one of the following:
/root/.mozilla/eclipse/Cache (for root user)
/$HOME/.mozilla/eclipse/Cache (for non root user)
Delete all the data from the Cache directory.
Restart iManager.
~end quotation~
Workaround: to check if the issue is with the embedded Mozilla browser included with iManager Workstation, start iManager and minimize it. Then open Firefox or Internet Explorer and type in http://localhost:48080/nps in the address bar. If iManager works fine in that browser, the above fix will likely be sufficient.
I’m still looking for how to configure iManager Workstation to run in Firefox rather than the embedded version of Mozilla included so if you find it, please share!
↧
↧
Recordings/Survey for the Novell Technical Training Webinar Vol. 5 - Especially for K12
In order to make The Novell Training webinar series more effective, please provide your feedback. Visit the following link to complete a short 2 minute survey and to receive the recordings of May's Novell Cool Success Webinar.
http://www.grouplink.net/redir.asp?id=2009051301
The agenda was:
“Using Teaming + Conferencing in K12” Phil Karren, Collaboration Product Manager
“GroupWise 8 - Migration Tips and Tricks” Tim Leerhoff, TIES (Minnesota education technology collaborative)
“Password Synchronization and Universal Password” Mike Weaver, Concensus Consulting
“OES Overview for K12” Jason Williams, Product Manager OES
We look forward to your feedback. Look for next month's webinar information to be posted shortly.
To view the archived Webinars visit: http://www.grouplink.net/redir.asp?id=2009022001
↧
Universal Password Policy Change GUI Tool
license:
Free without warranty This tool is a GUI for changing all the users in an OU with a particular password policy to another policy. It is primarily designed for cases where the policy is not associated with the OU but instead assigned to individual users. It is particularly helpful because iManager does not always seem to clear the user's npsmPasswordPolicyDN attribute correctly and changing dozens of users by hand is a pain.
Requirements and Technical Notes:
.NET or Mono 2.0. The tool does not use LDAP certificates for simplicity and speed, so just go ahead and use it on an LDAP server that accepts straight 389 port connections without requiring SSL/TLS (i.e. use it from a workstation that has an almost straight link to the server). Also note that this is basically a shell script with a GUI bolted on -- exception handling is minimal. I regard it as polished enough to publish, and it works well in my environment, but this is not a sterling example of best software engineering practice. It is written in C# using WinForms and the ADSI frameworks. It _does_ handle wacky policy names with spaces, slashes, etc.
Instructions for use:
- Enter your short novell admin username (the tool will find your context), password, and the LDAP server you want to query (see requirements above) and push the "Authenticate to eDirectory" button.
- Step one populates the Container, and Policy drop boxes. In order to avoid exceptions use the drop-box entries instead of just typing in your desired entries. Select the container you want to change (the tool handles only one container at a time and does not drill down into subcontainers), the password policy that the users are now assigned to, and the new policy to which they are being migrated. Then press the "Change Password Policy Button"
- When the process is finished, a log of results will be displayed in the big box at bottom.
Algorithm (For debugging):
- The program creates an admin connection to the LDAP server and checks that it is a valid connection. It does not check rights.
- All the containers in the tree are found and are displayed by short name in the container drop-down box. The values are the actual contexts (so a bit of OU "junk" does end up there -- Tomcat roles, etc.). Password policy names are found in the Security object.
- When the Change Password Policy button is pressed, the program does a filtered search and grabs every user in the specified container whose npsmPasswordPolicyDN attribute is set to the name of the old policy. It then loops user by user to change npsmPasswordPolicyDN to the new policy, removes the user from the nsimAssignments list of the old policy, and adds the user to the nsimAssignments list of the new policy (if not present already).
- It is supposed to update the results box for every user handled with a log of what it did for that user, but in practice the box doesn't seem to update until every user has been handled.
Source code available upon request. This was an internal project that I made universal enough to publish here, but you can probably improve its feature set and exception handling with a minimum of effort.
| Załącznik | Wielkość |
|---|---|
| passpolchange.zip | 47.04 KB |
↧
NetWare to Open Enterprise Server 2 Migration – Lessons Learned
Over the past couple of months, I have been involved with migrating remote NetWare servers to Open Enterprise Server 2 (OES2) Linux. During this time, there are some lessons that have been learned that hopefully this article will be able to help you, the reader, perform your own migrations more smoothly and avoid some of the pitfalls we encountered.
For organization purposes, I have put the issues and resolutions into group headings based on purpose, like printing or DHCP. There will be general issues and how we overcame them in their own heading.
There are now many sources for information on migrating NetWare to OES2, of which I have authored several, so your choices are not limited to just the Novell documentation, although very helpful. The forums are a very good source for, "What do I do's" and "What does this mean?" questions. I will be addressing specific issues that were encountered repeatedly and what was done to correct or resolve the problem.
DNS-DHCP
Locater Objects and disappearing Zones
When installing or configuring OES 2 in a production tree with DHCP already present, when specifying the context of the dhcpLocator and dhcpGroup objects, ensure you specify the up-most location of the existing dhcp objects, when you run your DNS/DHCP utility, the zones will appear to be ..gone.
If this happens, don't panic, your zones are still there in the tree, it's just you've defined a new locater and it doesn't know about the existing zones. If you use iManager or ConsoleOne, you'll see the zone and subnet objects in the tree.
Remove the newly created locater objects in the contexts you specified when you installed or configured DNS/DHCP and then start your DNS/DHCP Utility and everything will appear as it should.
DHCP Daemon Fails to Load
When running dhcpd on the OES2 Linux server the first time fails and reports the error, "insufficient credentials."
The admin account that was used to initially install and/or configure DHCP in OES2 has changed his/her password in eDirectory or is no longer valid.
Utilizing services for OES2 on Linux that use eDirectory access require an admin or equivalent account for the service to access eDirectory. This key pair is encrypted and stored in a hash on the SLES server and is used by these services. If the account's credentials change, then the access fails.
Launch YaST and OES Configuration and enter credientials for an account, we used a system type account, with admin equivalence and exempt from Universal Password Policies to ensure normal password change intervals are not enforced.
Upon saving your configuration, the service loads normally.
Location of DHCP Objects Post-Migration
After the migration of a location that includes migrating DHCP, you will notice that in the base container, or your base Organization, there will be an object called,
dhcpservice_OESDHCP_[NW-SERVERNAME]
This is the DHCP service objects for OES-DHCP Linux. This service can be moved to the desired container as long as it can be walked from the root to the DHCP server object itself. In other words, if your DHCP Server object is located in OU=NewYork,OU=Eastern,O=US, you can place the DHCP Service object in any of these containers. If you placed your DHCP Service object in OU=DHCPStuff,OU=Eastern,O-US, the DHCP Server object would need to search to a lateral container and it wouldn't find it.
If you create a new DHCP Service object in the tree, you can specify the container that the object is created.
Both scenarios were performed during the migration and it was found that creating new DHCP services and subnets was more efficient and using the migration utility.
Migrating from NDPS to iPrint produced it own challenges. Once again, migrations were performed with the migration utility and some were performed by simple creating new IPP printer objects. And Again, it was found more efficient in both reliability and time to create the iPrint objects, Driver Store, Print Manager and Printers from scratch, especially in smaller locations. If you have a large, 100+ printers, definitely use the migration utility.
Assigning printers to users was used by running an LDAP search against the users in a particular container and retrieving their current NDPS printer assignments.
ldapsearch -x -h [servername] -D "cn=admin,o=org" -W -b "ou=newyork,o=org" objectclass=inetorgperson ndpsPrinterInstallList ndpsDefaultPrinter >newyork.ldif
This command will create a text file with the users DN and the printers assigned.
It also informs you which printer is the user's default printer.
It will look something like this:
## newyork.ldif # extended LDIF # # LDAPv3 # base <ou=NewYork,o=Org> with scope subtree # filter: objectClass=inetorgperson # requesting: ndpsPrinterInstallList ndpsDefaultPrinter # # TKing, NewYork, Org dn: cn=TKing,ou=NewYork,o=Org ndpsPrinterInstallList: cn=HP4000-1,ou=NewYork,o=Org ndpsPrinterInstallList cn=HP4000-2,ou=NewYork,o=Org ndpsDefaultPrinter: cn=HP4000-1,ou=NewYork,o=Org#1246908645#1 # RJames, NewYork, Corp dn: cn=RJames,ou=NewYork,o=Org ndpsPrinterInstallList cn=HP4000-1,ou=NewYork,o=Org ndpsPrinterInstallList cn=Xerox5632-3,ou=NewYork,o=Org ndpsDefaultPrinter: cn=Xerox5632-3,ou=NewYork,o=Org#1246728603#1
what we want to do is take this list and modify it to reflect the new IPP Printers and then do an LDAP Modify to add them to each user.
If we create an IPP printer and then assign it to a user, there is an eDirectory pointer that is assigned for that printer. In ConsoleOne, if we look at the user we assigned the IPP printer, and click the Other tab, we can see this code pointer.
Look at the attribute, iPrintiCMPrinterList. Expand the attribute and there will be a 10 digit number. Write this number down. Now, below that 10 digit number will be a numeric value of 1 or 5. 1 means the printer is assigned to that user. 5 means that that printer is the user's Default Printer.
Create a new ldif file, I used the existing output from the query. Replace ndspPrinterInstallList: with iPrintiCMPrinterList: append #[ten-digit-code]# to the end of the entry and place a 1 or a 5, remembering that only one printer can be the Default. It should look similar to this:
iPrintiCMPrinterList: cn=HP4000-1,ou=NewYork,o=Org#1246908645#1
Add to each user entry, iPrintiCMPrinterFlags: 1, this allows the modification of the users IPP printer assignment.
Remove the line stating the ndpsDefaultPrinter
The above users entries should look similar to this:
## newyork.in # extended LDIF # # LDAPv3 # base <ou=NewYork,o=Org> with scope subtree # filter: objectClass=inetorgperson # TKing, NewYork, Org dn: cn=TKing,ou=NewYork,o=Org iPrintiCMPrinterList: cn=HP4000-iPrint-1,ou=NewYork,o=Org#1246908645#5 iPrintiCMPrinterList: cn=HP4000-iPrint-2,ou=NewYork,o=Org#1246908645#1 iPrintiCMPrinterFlags: 1 # RJames, NewYork, Corp dn: cn=RJames,ou=NewYork,o=Org iPrintiCMPrinterList: cn=HP4000-iPrint-1,ou=NewYork,o=Org#1246908645#1 iPrintiCMPrinterList: cn=Xerox5632-iPrint-3,ou=NewYork,o=Org#1246908645#5 iPrintiCMPrinterFlags: 1
Now, once you have your printers created and the PrintManager and Driver Store are loaded and running, run the following command from the OES 2 Linux server to add the users' printers.
ldapmodify -x -h [servername] -D cn=admin,o=corp -W -f /path/newyork.in
If you don't get any errors, you can verify the settings in ConsoleOne or through iManager - iPrint User Management
Removal of the old NDPS printers from the user's local profile is fairly simple. Once your migration is complete, remove the NDPS Manager and the NDPS printers will be removed from the users' workstation the next time they log in. You must still delete the NDPS objects from the tree manually.
The above process for printer query and assignment was developed for our team by Michael Bruner. Pretty Sweet process and a big time saver.
File System
File system migration is fairly straightforward, keeping in mind some gotchas that could pose a potential hair-pulling session.
- Make sure that any virus scanning software on both the Source and Target server is offline and not running. Although it would catch any potentially infected files, some features could prevent the file copy altogether and ultimate failure of your migration.
- Migrate non-user data first. Directories like, Zenworks and static type directories can be migrated without worrying about them changing while the migration is in progress. We migrated this data during the day and then the user data after hours and this saved a lot of time waiting for 10+GB of data to copy from one server to the other.
- Migrate user data separately and perform a preliminary migration during regular hours, then perform a Sync of the data after hours to catch any files that might have changed.
- Once all the data has been migrated to the new OES 2 Linux server, dismount your data volume on the NetWare server. This will prevent users accidentally mapping a drive or having a local mount point to the old server.
- Unless you are doing a Transfer ID migration, change your login script to reflect the new servername once the data is migrated. This will also prevent remote access users, VPN, etc, from logging to the old server while you are still finishing up. Disabling login on the old server will only prevent you from migrating anything.
General
Let your users know that the first time they login the next day, that in general, the login will make some backend modifications and, if you run ZENworks Novell Application Launcher, (NAL), the client will re-cache everything and it's going to take a few minutes. Also, SLP and iPrint will take a few moments to install any printers assigned prior to migration.
If you use RSYNC for backup, make sure that port 873 is open on the OES 2 Linux server. The errors you get are confusing and seem to be DNS related when it's simply being blocked at the server.
Post Migration Issues
There are a couple of things that have been observed post migration, mostly related to the clients, mainly SLP. OES 2 uses OpenSLP and if you have an UNSCOPED setup, you'll need to add the DA's to each workstation's registry either manually or through an application push. Same with the iPrint Client. Do these items a week to two weeks prior to migrating and you should have no "Tree or Server Cannot be Found" the morning after migration to OES 2 Linux.
We did not migrate iFolder, NTP or FTP as these were not part of my current environment. When the servers were built NTP was set up independently.
Conclusion
Migrating to OES 2 Linux has been a wonderful learning experience and also, a lot of fun. We had some nail biting moments and gained far more Linux knowledge than we had when we started. I hope this information is helpful to you in your own migration process.
Enjoy!
↧
OES Updates on Twitter
Introduction
Twitter is decribed by Wikipedia as "A free social networking and micro-blogging service that enables its users to send and read messages known as tweets. Tweets are text-based posts of up to 140 characters displayed on the author's profile page and delivered to the author's subscribers who are known as followers. Senders can restrict delivery to those in their circle of friends or, by default, allow open access. Users can send and receive tweets via the Twitter website, Short Message Service (SMS) or external applications."
Twitter's Popularity
Last March, Twitter was ranked as the fastest-growing site in the Member Communities category as indicated by a Nielsen.com blog. Twitter had a monthly growth of 1382%, Zimbio of 240%, followed by Facebook with an increase of 228%.
Twitter is becoming a popular tool for businesses and corporations to extend their reach to their customers. In addition, customers get added benefits by receiving immediate information on their favorite products and services and in some cases they get promotional offerings not found else where. Dell for example has benefited from using Twitter by receiving immediate feedback from its customers while at the same time giving its customers discounts that can't be found elsewhere. See( http://www.reuters.com/article/internetNews/idUSTR... ). How could your business benefit from using Twitter?
OES Updates on Twitter
Novell has several different accounts on Twitter, but we have now added an OES specific one. You can now get immediate updates on Twitter with what is happening with Open Enterprise Server. Just follow the Twitter account "novelloes" at http://twitter.com/novelloes.
If you don't have an account you will find a button (at the above link) to create an account. You can also send feedback to us about OES, by starting your tweet message with @novelloes.
Two recent "tweets" are the announcement of the OES2SP2 Beta3 which was recently released to the beta sites. Also posted was news about the Novell Support Advisor tool (v. 1.1) which just shipped this week, which scans your servers for potential problems and gives possible solutions, saving you from potential support calls. You will also get periodic updates on other interesting OES happenings that you might not otherwise find out about. Enjoy, and I hope to see you all on Twitter.
↧
↧
Exporting the SSL Certificate Using iManager
This cool solution explains how to export the Trusted Root Certificate of the eDirectory Server, that is used for LDAPSSL authentications.
- Log in to the eDirectory tree (whose SSL certificate is iManager with a valid user with proper rights.
- Go to the 'Directory Administration' tab on the left panel.
- Click on the 'Modify Object Link'.
- Click the 'Object Selector' and browse through the tree to find and click the 'SSLCertificateIP' object.
- Now click Ok.
- Go to the 'Certificates' tab. And select 'Trusted Root Certificate' underneath that.
- Select the 'SSLCertificateIP' certificate check box. If there are more than one certificate present, select the appropriate one.
- Click on the link 'Export'.
- In the 'Certificates' drop down box, select 'SSL Certificate IP'. Uncheck the 'Export Private Key' option.
- Select the 'Export Format' as 'DER' from the drop down menu. And click 'Next'.
- Click on the 'Save the exported certificate' link and save it in your machine locally.
Later on, this certificate can be used for LDAP SSL authentication against the corresponding eDirectory server.
↧
Manual Uninstallation of ZENworks Server Management iManager Plug-in
Authors: Sanjeev Kumar, Poovizhi Palanisamy, Dodda Venkata
If you have installed a ZENworks Server Management plug-in through iManager 2.7.2 or earlier versions and try to uninstall this plug-in through iManager 2.7.3 or later version, the plug-in does not get uninstalled properly.
This Cool Solution describes how to uninstall the ZENworks Server Management plugins manually.
Uninstallation Steps
Uninstallation of ZSM Plug-in Does Not Happen Properly
In this case, you must manually uninstall the plug-in by removing the following directories:
- Stop the tomcat service.
- \<Tomcat>\work\Catalina\localhost\nps\org\apache\jsp\portal\modules\zfs
- \<TOMCAT>\webapps\nps\portal\modules\zfs
- \<TOMCAT>\webapps\nps\WEB-INF\modules\ZENWorks Server Management (The
MANIFEST.MF file is present in this directory and must be deleted) - Remove the following files from location \<TOMCAT>\webapps\nps\WEB-INF\lib\
Admin.jar CPKAgent.jar CPKAgentRes.jar ConsoleOne.jar DesktopAgent.jar DesktopAgentRes.jar FTPAgent.jar FTPAgentRes.jar FileAgent.jar FileAgentRes.jar HTTPAgent.jar HTTPAgentRes.jar MSIAgent.jar MSIAgentRes.jar PolicyAgent.jar POlicyAgentRes.jar RPMAgent.jar RPMAgentRes.jar RWCEMFramePlugins.jar TEDLib.jar TEDLibRes.jar TEDWebSnapins.jar TestAgent.jar Widgets.jar ZCommon.jar ZcommonRes.jar ZENLicensing.jar ZENLicensingRes.jar smanager.jar xmlrpc.jar xmlrpcext.jar zenCommon.jar zenloader.jar
- <TOMCAT>\webapps\nps\packages\ZFS_PolyDistPlug*
- You must also delete the UninstallerData directory for the ZENworks server management plug-in to delete. The UninstallerData directory is present in the following path:
NetWare:
SYS:\tomcat\5.0\webapps\nps\UninstallerData\Uninstall_ZENworks Server Management SYS:\tomcat\5.0\webapps\nps\UninstallerData\Uninstall_ZFS*
Windows:
C:\Program Files\Novell\Tomcat\webapps\nps\UninstallerData\Uninstall_ZENworks Server Management C:\Program Files\Novell\Tomcat\webapps\nps\UninstallerData\Uninstall_ZFS*
Linux:
/var/opt/novell/tomcat5/webapps\nps\UninstallerData\Uninstall_ZENworks Server Management /var/opt/novell/tomcat5/webapps\nps\UninstallerData\Uninstall_ZFS*
- Restart the Tomcat service
↧
End-User Computing Enablement Resources
Attention
- This page is being transitioned to something much better!
- All new sales resources will be posted to End-User Computing Partner Enablement Central.
- This page will remain in place for historical purposes.
↧
More Pages to Explore .....
