We needed a helpdesk and a knowledgebase system and we prefer that it be opensource. We have found OneOrZero HelpDesk and KnowledgeBase to be a good candidate. We decided to take a look at it and see for ourselves. Installation was tad easy. All you need is an Apache server, PHP, and MySQL and voila! We have been running it using MySQL for sometime but we didn’t as of yet let users use the system.

We have been mulling over the idea of integrating OneOrZero HelpDesk and KnowledgeBase authentication with our existing LDAP server which also authenticates our Windows domain users via our Samba PDC. OneOrZero is pretty much convenient for us since it already has LDAP authentication capability. Or so we thought.

Setting up LDAP for OneOrZero HelpDesk, required us to modify its settings. You can do this using its own control panel, by logging in as an administrator, or you can go brute it out by going to where the OneOrZero configuration files are located. In my case it is in

/srv/www/onezero/configuration/website_settings.php

Please note that the location may not be the same in your case, depending on where you extracted your files, and where your Apache DocumentRoot is located. Make the necessary adjustments.

After locating the file, make a copy first of the existing file (you dont want to lose working settings do you? then edit website_settings.php by opening your favorite text editor - which in my case is VI.

vi website_settings.php

Navigate your way down towards near the end of the file, and review the LDAP-related parameters. Please note, I’ll be using my own LDAP parameters as examples and yours might be different depending on your LDAP server flavor (AD, OpenLDAP, Netware/OES/others).

# Enable LDAP authentication. This is DB by default.
auth_method = "LDAP"

# IP address of your LDAP server
ldap_host = "192.168.10.10"

# If you are using AD, specify the domain name. I'm using OpenLDAP so, I ignored this.
ldap_domain = ""

# Specify the user that will be used to bind to your LDAP server. Not needed if anonymous bind is allowed
ldap_binddn = "cn=ldapbinder,dc=mydomain,dc=com"

# Specify the password for the binding user
ldap_bindpwd = "secret"

# Set the location in your LDAP schema where the search will start from. In my case, I have an OU called "Users"
ldap_rootdn = "ou=Users,dc=mydomain,dc=com"

# Provide here the search attributes. Note though that this might be different on your particular flavor of LDAP.
# Use an LDAP browser utility to double check.
ldap_searchattr = "uid"
ldap_fname = "givenname"
ldap_lname = "sn"
ldap_uname = "uid"
ldap_email_add = "mail"
ldap_office = "l"
ldap_phone = "telephonenumber"
ldap_context = "dn"


Save your file after editing.

We then tried logging in using our LDAP accounts, however it seems that OneOrZero cannot find our accounts, or rather LDAP cannot find the accounts passed by OneOrZero to it. So, I then looked at the LDAP log and checked what the problem is. Sure enough, I found the culprit.

Jan 14 11:18:15 x2100 slapd[4044]: conn=5857 op=1 SRCH base="ou=Users,dc=mydomain,dc=com" scope=2 deref=0 filter=”(uid=minime)”

No wonder LDAP cannot locate the user. Even though it is searching on the right section of the LDAP tree, it doesn’t know which one to pick up. Remember, we use our LDAP server as authentication for our Windows users via Samba as well. Heck, we even authenticate our SSH users via LDAP also.

Another challenge!

How do I hack the filter in OneOrZero so that it works for my LDAP server ? (GOD I LOVE THIS WORK!)

Simple, I have to locate the filter string deep in the vowels of OneOrZero’s source code and insert my own filter or manipulate it so that the output filter will meet what my LDAP server really needs.

OK OK! Enough suspense, how did I do it? Simple.

Navigate yourself to where you extracted OneOrZero - in my case /srv/www/onezero/common , and edit the file common.php . When you open the file, navigate yourself towards line 164 . There you will find the $filter variable which receives the value from the LDAP search attribute that was set in website_settings.php .

When you locate the $filter variable, comment the existing one, and replace it so that it looks like this:

// $filter = "($ldap_searchattr=$name)"; //This is the default filter string

$filter = "(&(objectClass=posixAccount)($ldap_searchattr=$name))" // This is my new filter string to fit my LDAP server.

Save the file and do a test login. That’s it!

If you still have trouble setting it up (which I doubt), feel free to look at the Administration guide at http://www.oneorzero.com/wiki/index.php?title=OneOrZero_Settings

Enjoy!

Technorati : oneorzero, helpdesk, linux, ldap, authentication
Site Search Tags: oneorzero, helpdesk, linux, ldap, authentication

I’ve somehow finished implementing Samba as primary domain controller (PDC) with OpenLDAP working as authentication backend both running on top of SuSE Linux Enterprise Server. Workstations and users are being added properly into Samba and OpenLDAP and users are able to authenticate seamlessly. However, I just ran into a snag. Some users need to be Administrators in their own computer, while being common users in the domain.

It really is no sweat implementing Samba and OpenLDAP on SLES since it already includes both packages stabilized and ready to run. Novell engineers already did the grunt work of tweaking and hardening both packages plus with the help of YAST, I don’t have to use the smbldap tools to synchronize accounts on Samba and OpenLDAP. No sweat eh?

What I had trouble was how can I select only specific users from Samba PDC/OpenLDAP and make them Administrators to their own machines. I’ve looked for solutions however many of them were not fitting to what I want. So I decided to use KiXtart and CPAU instead.

In a nutshell, KiXtart replaces your standard batch file logon script and give you more flexibility and power than you normally get from batch files. CPAU on the other hand replaces the traditional Run As command on Windows. The main difference is that although Run As allows you to run a command as another user (or admin), however, you will be prompted with that user’s password in the same manner that you use SU on Linux/Unix. CPAU allows you to speficy the user and password inline giving you more flexibility with your scripts.

So to add users to the local machine’s Administrators group, I put the KiXtart binary (WKiX32.exe) and CPAU.EXE in Samba’s NETLOGON folder and modified smb.conf to reflect the following:

logon script = logon.bat

In logon.bat, put the line:

%0\..\wkix32.exe %0\..\kixtart.kix

The next part does all the grunt work in identifying the user’s domain group, and checking if the user is a part of the local machine’s Administrators group.

kixtart.kix

Break on

$loffmsg = "Hello "+@USERID+CHR(10)+"This is your first time to logon to the domain."+CHR(10)+"Since @WKSTA is your own computer, you will be added immediately to the local"+CHR(10)+"Administrator group."+CHR(10)+"You will need to log on again afterwards."+CHR(10)+CHR(10)+"Username: "+@USERID+CHR(10)+"Host: "+@WKSTA+CHR(10)+"Group: "+@PRIMARYGROUP

; Check user domain group membership

IF INGROUP("Domain Admins")=1

; Check user local group membership

IF INGROUP("\\"+@WKSTA+"\Administrators")

; Do nothing.
MessageBox("Hello "+@USERID,"Greetings!",,)

ELSE
; Hide the console KiXtart is running on

SETCONSOLE("HIDE")=1

; Run CPAU tool with admin priv to add user to local admin group
MessageBox($loffmsg,"Reminder",64,)

shell '\\MYPDC\netlogon\cpau -u administrator -p admin-password -ex "net localgroup Administrators /add DOMAIN\@USERID" -lwop'
; If there's error, show it.

IF @ERROR MessageBox(@ERROR+@USERID,"Error!") ENDIF

;Force the user to logoff after being added so the change will take effect next log on.
LogOff(1)
ENDIF
ELSE
ENDIF

Further development
I’m still far from done with this little project. I still have to modify the script, or add some more subscripts, to be able to check if the local machine is the user’s own machine. I will need to implement that the user will only be admin on his own machine and none other. And yes, you can also use KiXtart to modify the registry if you need to.

Security? You can compile your kixtart script into an EXE executable using the KiX2EXE tool.

I’m just glad that I get to make Windows XP machines play nicely with Samba and OpenLDAP.

Resources:
KiXtart Online Manual
KiX2EXE Tool Homepage

Technorati samba, openldap, linux, windows+xp, kixtart, domain, controller, pdc
Site Search Tags: samba, openldap, linux, windows+xp, kixtart, domain, controller, pdc

In an enterprise environment, it is quite a challenge for administrators to be able to quickly and efficiently deploy a bunch of network services on top of Linux. Services like web(http), ftp, DNS, DHCP, SSH, and the like require some configuration time, proper planning, and discussion with the deployment team, auditing team, and helpdesk teams. Rolling out a set of physical servers is also another area where improvement in deployment speed is almost equivalent to a the success or failure of your business.

Choosing what platform or operating system to leverage on for your environment is also another key decision. Depending on an enterprise’s requirements, you may opt to go for Linux, pure Unix, Windows (yeah it too is an option by some standards), and even Mac OS X. You might ask, “How come Netware is never mentioned?” Well, it is quite obvious. Despite the strength and reliability of Netware, the low volume of applications that could be had on the platform has almost put it to near obscurity. However, those who are still using Netware continue to profess to its rigidity, solid performance, and reliability.

What will happen to Netware? Actually, Netware is not dead. It is alive and well, and Novell continues to nurture the still breathing, and would you believe it - growing, community of Netware users. Yes, yes, I’ve said Netware was put to near obscurity. Got it? N-E-A-R. It’s not obscure. It’s not dead. It is just low under the radar compared to other platforms like Windows, Linux, Solaris, and others. Again, its community is growing.

How on earth is it low on the radar and yet growing? Simple. Novell is slowly morphing Netware. From a pure Netware operating system, it is now a hybrid operating system. Novell called it Open Enterprise Server (OES). Open Enterprise Server is both a Linux system and a Netware system. On one hand you can install it as a Netware-kernel based server, offering the same traditional Netware services. On the other hand, you can deploy it as a pure Linux system, based on SuSE Linux Enterprise Server 9, offering traditional Linux services like any other Linux distribution and yet also offering the Netware services that you can only previously find on Netware. Services like Virtual Office, Edirectory, iFolder, and Netware Storage Services, are just a few of those services traditionally found on Netware.

Novell Open Enterprise Server 2 Public Beta
Recently, I have received an email from Novell’s Beta Management Team informing me (and others in their mail list of course) that Open Enterprise Server 2 is now available as Public Beta release. OES 2 will complete the transition of offering Netware services on top of a pure Linux system.

Solid Under the Hood
OES 2 runs on top of SuSE Linux Enterprise Server 10 SP 1 leveraging the latest stable enterprise SuSE build fused with the latest Netware 6.5 services on an easy to deploy Linux-cum-Netware distribution.

Notable Improvements
Like any recent Linux distributions, Open Enterprise Server 2 has full support for 64-bit dual-core and multi-core processors. And just like its SuSE Linux Enterprise brethren, it also comes chockful ‘o virtualization goodness thanks to the built-in Xen Hypervisor technology that allows it to provide both paravirtualized and fully-virtualized environments of Windows, Solaris, or other Linux distributions.

The most notable development to date that the Open Enterprise Server 2 may offer is the Dynamic Storage Technology introduced in this build. Dynamic Storage Technology eliminates seldom-used data from taking up valuable space on your most expensive and highest-performing storage devices. As Novell puts it:

“Dynamic Storage Technology allows administrators to create policies that dictate what data is considered active or inactive. With these policies, inactive data is relocated to lower-cost storage solutions and is backed up less frequently. Active data then resides on highest-performing storage environments, is backed up more frequently and is first to be restored in the event of a disaster. End users see no change in the way they access their information, but the data is automatically optimized based on policies and actual use.”

Another key development to this build is called Domain Services for Windows. In the good old days of Netware and the previous OES version, the only way for Windows workstations to authenticate to Edirectory will be via the Novell Client which must be installed on all machines. With Domain Services for Windows, workstations will no longer need to have Novell Client installed, and instead will communicate with Open Enterprise Server using native Windows protocols and authenticate themselves the same way they authenticate to Active Directory.

The same Domain Services for Windows also provided another way to manage OES on top of Windows — via the Microsoft Management Console. Netware and the previous OES version is managed via ConsoleOne or iManager. Now, administrators can perform certain file system and directory tasks, as well as centrally administer Samba shares via the MMC.

Me and my team are still currently evaluating the current beta build and it might be a month or so before the final stable release. However, we are very excited to see this thing run and look at what it can do. Who knows, this might just allow Windows Server 2003 make a run for its money.

Links:
Novell OES Product page
Novell OES 2 Public Beta Download page

Technorati: OES, Open, Enterprise, Server, Novell, Netware, Linux,
Site Search Tags: OES, Open, Enterprise, Server, Novell, Netware, Linux,