Today we’re going to look at configuring the Pentaho business analytics integration server at LDAP. To do this, we’re starting off with a vanilla build of Pentaho business analytics and the data integration server.
We’re going to log in as a regular user, configure the LDAP settings, and then restart the server.
After we restart the server, we’re then going to go in and test that we can login via LDAP and once we’re able to test that that’s all working correctly, we’ll then go in and configure the data integration server by simply going in and copying over the configuration we’ve just built inside the business analytics server.
So let’s start off with our vanilla build. We’ve got here a very typical Pentaho User Console. We’re just going to login with the general admin user login – I haven’t done any configuration here.
Uername is: admin, Password is: password.
The next part of this exercise is to go onto the administration prospective. You go onto authentication and here we’re able to select the LDAP or active directory, and you just click yes.
The first part we need to do is configure our connection, so I’ll just drop some values in here. And now we’re connected to our LDAP server.
Pentaho has added some nifty features, which include being able to select values from a directory tree to find your users.
What we’re configuring here is the administration user. I’m just gonna grab our managing director and use his details.
Now the problem is, Pentaho has configured this so you’re selecting the username and password via the tree. But the thing is, when you’re connected to LDAP, you normally don’t use this “cn”, you usually use your user ID.
So what we need to do is change that from cn to UID=Zach, rather than the cn name. The cn name will still be used for the LDAP service.
The next part that needs to be updated is because we’re using a generic LDAP, we’re not using the apache directory service we need to change this to custom configuration if you’re using active directory you’ll also need to use custom configuration and you’ll to need to use slightly different search requests from what I’m using here.
The next part of the exercise, we’re going to say that our search credentials are going to be our user tree and we want to base it on rather than the CN rather than the user ID.
You can see in the apache user directory (I’ll just reconnect to this).
So you can see in the tree structure here is Sydney, BizCubed, Com and it’s under accounts – users – and here are all the users, and then for me, we can see the UID is John, for Zach, the UID is Zach, so we’re going to use that for our setup.
That application is our apache directory studio – I highly recommend using it or something similar when you’re configuring this.
It will help you understand what settings you should be using in here or what searches you can put in.
The next part that we’re gonna put in here is the object roll that we want. Now, I haven’t completed this from where I’m pasting it out of, so what I want to do is I’m going to add in here a CN=Pentaho*.
So what this is telling the system to do is it’s going to go into the groups folder and look for anything that’s got the class of possicks group and the name starts with Pentaho.
So, if we test this, you can see we get back the Pentaho authenticated, Pentaho admin, Pentaho dev and Pentaho CEO. If I remove that little filter, that’s going to change the scenario and it should give back all of my LDAP roles that we’ve got defined in there. So, I want it limited, so I’ll just put that back. To find the users one, put in a test account, and that should populate all your different settings in here.
So the test features are really useful to be able to understand what’s going on and that everything’s working correctly. Alright, so we’ll just put back in here our group role search, and the next part that we want is our version of LDAP, you want to be part of the members category.
So if I go and look at the Pentaho admin role, you can see that there’s an element role called members, and here are all the members in that group. And we don’t have a role prefix so we can just leave it alone. Now you can test that in a few different ways, let me just grab that user. Now to test, we can put the user in here, the name is Zach and if we hit okay, it’ll come back saying it’s authenticated correctly.
So we can save this and it’s going to come up saying everything’s been saved but we need to restart the server for it to be correct. So let’s log out and log back in. We’ve got the server on a yubuntu server, let me just go and stop it.
Okay, so that has stopped. Now if we go into the Pentaho system folder, we can see that Pentaho has gone in there and done some modifications on some files, so it’s updated the security properties, it’s updated the repository.spring file, and it’s updated the application context LDAP file. So the security, all they’ve done, is change it to be the provider=LDAP rather than Jack Rabbit which is the default.
In here, the big change from what was the default is here – they only update the single-tennanted admin username. What Pentaho is going to do behind the scenes take what we setup as our administration user and our administration role, and automatically replace that wherever it sees administration inside the system, so we don’t need to make any changes there.
So, if we go in to have a look in application- security- in here we can see that we see the administration group as set, administration user enrol, so we have Zach and Pentaho admin. It doesn’t, however, set the ‘all users’ roles. Now, this doesn’t seem to be a problem for the BI server, but when we go and copy this over to the DI server, the DI server doesn’t like it.
I’m just going to change it here. So this should be posicks, we’re going to put in there Account. Which will be the cost type. This here, needs to be users, and we need all the other stuff from up here. So the search path will be users, accounts, Sydney, BizCubed etc. The last one which we’re looking for the attribute User ID, which is completely correct.
So we’ll just go in there and save that. And now we can go in and restart the server. So, we’ll start it with login turned on, so I can actually see what started it. I do expect to see a couple of errors here because it’s going to start looking for a user called admin in a couple of places and that user no longer exists because it’s talking to the active directories.
If I refresh this, we’ll find the admin password no longer exists, so if I login as myself, I’m now able to connect to the server successfully and I can come in here and have a look at the administration role, so you can see now that in administration, it’s got this admin role.
So what it’s done is actually replace the role we originally called it, which was Pentaho – admin, in our LDAP and it has mapped that to administrator, and the normal case is that it has a secondary role which is called authenticated, and the authenticated role is deprecated and it assumes that if you can login to your LDAP, you are authenticated.
You can lock it down to a role, however you need to modify all the normal files, so the
Pentaho.XML and a few other files that say what an authenticated user role really is. Under here, you can still see our LDAP settings, that we can successfully login, and setup our server. One thing to note is that it automatically creates an entry for executing audit logs, it looks like the audit log has executed here. What will happen is because it has been told to run as admin, it’s going to crash as it will say that user is no longer valid. It’s good to come into the schedule and tell it to re-run which will tell itself to refresh and say it’s now me that’s running it.
Edit it, hit okay, then it becomes me and schedule it, and it will go off and run in the background. So you’ll see now it’s running on the logs, so that’s all fine.
You’ll notice there’s multiple instances where it’s running, so I’ll just delete them. So that’s everything set up nicely. So now I’ve got a complete LDAP installation and everything’s fine. To do the DI server, it doesn’t have a nice console, so if I connect to the DI server at the moment the only thing I’m going to see if I log into it, which will just be the admin password. This is the interface you get, there’s no way of automating this, so we’ll set that up for LDAP in here.
So, let’s go setup the DI server, go to my one directory, to my data integration server, so you just need to copy from the BI server the appropriate file, and overwrite them in here, so if I do an LS-L, so now I know which files we need to copy. So if I just do cp Pentaho BI system, copy that to local, then we’ll be doing an application context. So now we can see those three files have been updated.
The next step is to shut down our DI server, and we’ll start it up again. So that’s connected, we’ll come to here, we’re looking at the DI server, because it’s 90/80 at the top there in the URL, do a refresh of that.
As admin, passwords should no longer work, which is correct. If I use John (it didn’t redirect the first time, but there it is all fine). We can see that everythings loading correctly here. If you open up the data integration client, I can connect to the repository, and my repository settings are as per normal and just pointing to the server like we were before. Now I’m connected to the repository.
Because this is a vanilla installation, nothing exciting in the repository anyway, so there’s no content per se in there.
What we can see is that my roles and what security rights have been given and you can see there is an administration role, but you can see the administration role has been converted back to what we’ve set here as our administration role. So this administration role here now automatically links to anywhere in the system where it has administrator in the role.
I hope this has been a useful exercise. Lots of people have great fun with LDAP version of Pentaho, so thank you very much for watching and we’ll have some more in the series later on.