Integrating Leopard Server With UNIX LDAP, Part 3
This is the third out of four articles on integrating Mac OSX 10.5 (Leopard) Server with an external, UNIX-based LDAP server in a way that the collaboration services — wikis, blogs and calendars — in Mac OSX are available for users and groups in the external LDAP directory as if they were native users.
The first article describes how to add the appropriate Apple LDAP schema to your external directory. The second article describes how to set up appropriate partitions (e.g., cn=config, ou=MacOSX…) in your external directory to hold data from the Apple server. This article tackles the augmentation of user records in the external directory so that OSX Server recognizes them as native users.
1. Update the UNIX User Records in LDAP
First, extract a user account from Open Directory, to see what object classes and attributes Apple uses:
$ ldapsearch -v -x -D 'uid=diradmin,cn=users,dc=netmojo,dc=ca' -W -b 'dc=netmojo,dc=ca' -s sub "uid=testuser"
password: xxxxxxxxxxx
# testuser, users, netmojo.ca
dn: uid=testuser,cn=users,dc=netmojo,dc=ca
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: apple-user
objectClass: extensibleObject
objectClass: organizationalPerson
objectClass: top
objectClass: person
uidNumber: 666
apple-generateduid: B7A968BD-12A2-41D2-8FF8-09F4C2AEE405
apple-mcxflags:: PD94bWwgdmVy...
loginShell: /bin/bash
gidNumber: 20
userPassword:: KioqKioqKio=
uid: testuser
cn: Test User
authAuthority: ;ApplePasswordServer;0x47f...,1024 35
132011037 ... root@leopardserver.netmojo.ca:123.456.789.12
authAuthority: ;Kerberosv5;0x47f...;testuser@MYREALM.CA
;MYREALM.CA;1024 35 1320110 ... root@leopardserver.netmojo.ca:123.456.789.12
homeDirectory: 99
apple-user-homeDirectory: /Network/Servers/leopardserver.netmojo.ca/Users/testuser
givenName: Test
sn: User
UNIX LDAP directories will vary widely in the type of data that they have for user accounts. I assume that your records have the usual posixAccount and shadowAccount objectclasses, as well as the standard user-account attributes, such as uid, uidNumber, gidNumber, loginShell, homeDirectory, etc.. If you want to use the full suite of services available on your Apple server, you will need to modify your user account records so that they include at least the following objectclasses and attributes:
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: extensibleObject
objectClass: apple-user
authAuthority: ;basic;
apple-generateduid: F1D0837A...
apple-user-homedirectory: /Network/Servers/your.nfsserver.com/home/
displayName: Firstname Lastname
givenName: Firstname
You can update your UNIX records using any tools that you like. You could use an LDAP editor of your choice, or the somewhat awkward tools that Sun provides with Solaris.
However, if you’re working with hundreds, or thousands of users in your UNIX directory, you’ll want to use a script to modify them automatically. I wrote this perl script to do the job. Feel free to use it, if you understand perl and know what you’re doing.
2. Update the indexes in your LDAP directory
The Apple server will perform a lot of queries on your LDAP server, so unless often-searched-for attributes are indexed, your Apple server and possibly your UNIX server will become quite sluggish. By examining the LDAP logs to see what OSX Server is searching for, we know which attributes should be indexed:
[08/Apr/2008:19:43:59 -0600] conn=13900 op=253 msgId=254 - SRCH base="ou=people,o=myorg" scope=1 filter="(&(objectClass=apple-user)(|(apple-generateduid=5408D7B6-XXXX-43C6-YYYY-549A7777688E)))" attrs="uidNumber apple-generateduid uid cn gidNumber sambaSID apple-generateduid"
...
[08/Apr/2008:19:44:12 -0600] conn=13900 op=255 msgId=256 - SRCH base="cn=computers,ou=macosx,o=myorg" scope=2 filter="(&(|(objectClass=apple-computer))(|(apple-generateduid=5408D7B6-XXXX-43C6-YYYY-549A7777688E)))" attrs="uidNumber apple-generateduid cn gidNumber ttl sambaSID macAddress apple-generateduid"
...
[08/Apr/2008:19:44:18 -0600] conn=13900 op=261 msgId=262 - SRCH base="ou=group,o=myorg" scope=1 filter="(&(objectClass=apple-group)(|(apple-serviceslocator=*mailingList*)))" attrs="cn apple-serviceslocator apple-group-memberguid apple-group-nestedgroup apple-serviceslocator"
...
...and so on...
To add attribute indexes with Sun ONE 5.x, start the LDAP console application,
Some of the attributes below are site-specific, and you may not even have them in your list, so ignore them. Sluggishness went away when I added many of these attributes to the index list:
apple-generateduid
apple-group-memberguid
apple-group-nestedgroup
apple-group-realname
apple-ownerguid
apple-realname
apple-servicelocator
automountKey
cn
gidnumber
givenName
ipHostNumber
ipNetworkNumber
loginshell
macaddress
mail
mailAlternateAddress
mailHost
member
membernisnetgroup
memberuid
nisnetgrouptriple
owner
sambasid
sn
telephoneNumber
ttl
uid
uidNumber
uniquemember
Once you’ve selected added the attributes to the index list, click the Save button, then click the “Re-index suffix” button in the pop-up window. Select all or just the new indexes, and click the OK button to begin re-indexing. It’s quick and painless.
3. Bind the Apple Server to the UNIX directory
For this, you need to login to your Apple server and start the Directory Utility application. It is in Applications -> Utilities. I basically followed Rajeev Karamchedu’s instructions, under the “Mapping Remaining Attributes and ObjectClasses” heading.
One very important difference is that I’m running Directory Utility from the Leopard server that is hosting my collaboration services. So where he says “Login to the Macintosh Client”, actually login to your Leopard server.
Before you close Directory Utility, switch to it’s Search Policy tab, and make sure that your UNIX LDAP directory is listed in the search path for both Authentication and Contacts. There is a bug in the Apple teamserver that prevents authentication if the directory isn’t also in the Contacts search path. This is also probably why the inetOrgPerson, etc., objectclasses are necessary.
Once you have set up the attribute mappings, successfully bound your Leopard server to your UNIX server, and adjusted the Authentication and Contacts search paths, you should be able to access your UNIX user accounts with the native OSX tools.
4. Access the user records in Workgroup Manager
Open Workgroup Manager, and click on the Accounts tab. In the top-left, there is a tiny globe icon with a down-pointing arrow beside it. Click it.
A list of available directories should appear, and the UNIX directory that you just bound to should be among them. Select it, and your UNIX users should populate the list below. Congrats!
There is now only one more step to go to be able to assign wikis, blogs and calendars to your UNIX users: update the groups in your UNIX LDAP directory. I will cover that in my next article.
Note: If you just want users to be able to create blogs, and you’re not concerned with group blogs/wikis, you could probably add the
apple-serviceslocator attribute to your UNIX users, and get that functionality. Copy the contents of this field from a local user on the Leopard server. If you try this, let me know how it goes! My concern has been group wikis and blogs, and I haven’t tested with lone users.
Tags: LDAP, Leopard, open directory, osx-ldap-integration, sun, UNIX, UNIX LDAP
May 29th, 2008 at 10:41 am
Thanks for the article - I am working on a similar setup at my company with our SunONE LDAP servers and our Leopard XServes - have you had any luck getting iCal server working with the user accounts stored on the SUN LDAP server?
That is something I have not been able to get working yet - I’m fairly certain I have all the required attributes added to my user accounts in LDAP (apple-serviceslocator, apple-generateduid) - however the iCal server piece doesn’t seem to like the Username/Password combo for the accounts in LDAP vs the accounts in the local OD which work fine (even though the rest of the server components - like AFP net home dir logins, ssh logins, etc - work fine with the SUN account names/passwords)
May 29th, 2008 at 10:56 am
apple-mcxflags is probably also an important attribute.
I haven’t experiemented with the iCal server and UNIX accounts yet. One way to debug it is to watch your ldap-access logs on the UNIX server when you try to authenticate; find out what it’s looking for and failing to find.
With Sun ONE 5.2, the access log is:
/var/opt/mps/serverroot/slapd-[hostname]/logs/access
Also, you may want to make sure that there isn’t an SACL set in Server Admin, for iCal.
Please keep me posted on how that goes!
Thanks,
Brent
May 29th, 2008 at 11:14 am
Yes - I have the mcx-flags and mcx-settings set on the SunONE accounts too - I have told the iCal server to run with ‘ANY’ for authentication method, and I have the iCal service enabled for all users.
It looks like the xserve has created ical account settings for the users - since I can see the SUN user’s calendar in the list of calendars when I login in as an OD user - but I just can’t login as the SUN user through iCal - like it’s not happy that the password is a Crypt password on SUN LDAP and not in Apple’s Password server - was hoping to find out if others were seeing this too - will let you know if I ever figure it out.
May 29th, 2008 at 11:18 am
This thread might be helpful:
http://discussions.apple.com/thread.jspa?threadID=1382678&tstart=136
May 29th, 2008 at 12:41 pm
That link does help - thanks. Now the iCal app accepts the LDAP password - but now it says the calendar ‘could not be found’ - I’ll keep working on it. Thanks for your help - please let me know if you run into any Leopard/SunONE issues down the road and I’ll be happy to try and return the favor.
May 30th, 2008 at 7:52 am
Thanks for the article, I would not have gotten very far without your help. I am testing a similar configuration for our insitution and I found that wiki and blog would not authenticate without using the following commands on the teams server.
sudo serveradmin settings teams:enableClearTextAuth = yes
sudo serveradmin stop teams
sudo serveradmin start teams
Hope this helps anyone that is having a similar problem.
May 30th, 2008 at 8:47 am
Thanks for the comment, Erik. I had enabled that option, but forgot to mention it in my article. I plan to go back and set up SSL between OpenDirectory and my Sun ONE server. It will make a nice article.
My Sun LDAP servers already communicate with each other in a multi-master replica setup with ldaps, but OpenDirectory is very finicky for SSL. It requires matching forward and reverse DNS all around, and that those names correspond with the names in the certificate files. I’m not sure about the certificate authority requirements; hopefully we can get away with a self-signed CA.
June 12th, 2008 at 1:00 pm
These articles have been really great, and exactly what we are trying to do here. We have run into one problem - after following step 3 above to “Bind the Apple Server to the UNIX directory”, everything works perfectly. We can use WorkGroup Manager to browse and modify the accounts that we have updated according to step 1 above. (We haven’t modified all of the user records yet.) However, when we reboot the Leopard Server (10.5.3), Directory Services just continually crashes with a Bus Error. The only way to get it to come up is to manually replace /Library/Preferences/DirectoryService/DSLDAPv3PlugInConfig.plist with one that is very simple and appropriate for “RFC 2307″. (Meaning it does not contain any attribute mappings, etc.) Has anyone seen anything like this?
June 12th, 2008 at 1:31 pm
Thanks Patrick - that’s good to know. I haven’t updated to 10.5.3 yet, but I’m planning on trying it this weekend. I read that 10.5.3 included updates for “augmentation”, so I wonder if something changed that affects custom attribute mappings.
June 12th, 2008 at 1:41 pm
I have upgraded our 2 leopard servers to 10.5.3 and have not seen any Bus Errors on reboot. Could it be the permissions on your LDAP plist file?
Also after 10.5.3 update the ‘Import’ feature of workgroup manager (from the ‘workgroup’ server mode) now allows me to import Users from the SunONE LDAP server into the local OD where it creates the augment records automagically for those users for things like ichat attributes, etc - I am testing one of our leopard servers with that ‘Cylinder of Destiny’ type config right now.
June 12th, 2008 at 1:59 pm
Cool. I hadn’t heard of Cylinder of Destiny before — thanks :). Now that augmenting SunONE records works — assuming that your config testing goes well — the value of these articles is diminished quite a bit!
Then again, some admins may prefer to have LDAP user account data all in one place, instead of distributed between servers. However, I can’t think of any good technical reasons why one would integrate instead of augment.
June 13th, 2008 at 10:57 am
Thanks for the quick replies everyone. But I found the problem, and boy, do I feel stupid.
Turns out we had activated the local Open Directory Server on the Mac OS X Server box as a “master”, in order to dump the user account info in step 1 above. As most of you probably know, we should have turned that right back off. Evidently the system does not like getting its settings from another server when there is a local OD master running.
(In my defense, a nice error message would have helped, instead of Directory Server crashing on boot…)
Anyway, thanks to all. We are looking forward to fourth article!
June 14th, 2008 at 2:27 pm
Patrick: My OD is and always has been configured as a Master…
I installed the 10.5.3 update today. I was disappointed to see that this bug still hasn’t been fixed.
I didn’t get a crashing OD (I think) after the update, but there were problems relating to the external directory server attribute mappings. There was a Python process that was crashing over and over again, but the functionality of the server seemed OK, except that OD and the CrashReporter process was eating up CPU cycles like I eat chocolate chip cookies. Disabling the external directory stopped the crashing python loop.
I changed the server mappings from “from the server” to “RFC 2307″, re-enabled it, and I can I see all of my external users in WGM just fine. However, authentication to the wiki doesn’t work — it produces an error, “No attribute shortName”, which should be mapped to our ‘uid’ attribute.
I suspect that the 10.5.3 update changed the attributes and/or objectclasses, so the old mappings, stored in the external directory which did not get updated, cause problems. I’ll have to go through the process of dumping the user account LDAP info, and watching the external server’s access logs again to find out what it’s looking for, and accommodate. Or, go with “augmented” local/external hybrids stored in OD, as per the “Cylinder of Destiny” setup mentioned in this thread.
June 14th, 2008 at 8:46 pm
Wow, that’s not good news. I was really hoping that the object classes and attributes would at least stay compatible across minor OS updates. Is it possible that your mappings have just been lost? It seemed to me that when I switched from “from the server” to “RFC 2307″, the set of mappings changes, and it writes a new plist file reflecting that. In RFC 2307 mode, I can still see my users in WGM too, but I cannot edit any Mac-only fields. (For example, I can change a user’s name, but not the contact info such as address.) You’re probably aware of all this, but thought I’d ask, since you didn’t mention re-entering the attribute mapping changes after switching to RFC 2307.
BTW, I think your URL for “this bug” is not what you intended?
June 14th, 2008 at 9:52 pm
Hah! Thanks — I fixed the URL :).
No, I haven’t yet tried the Calendar server with external accounts. It wasn’t one of our goals. I think I read somewhere that it requires Kerberos, though. Solaris supports Kerberos, but if you don’t already have that set up, you’re looking at a lot of work. Or maybe you could get away with adding the “authAuthority: ;Kerberosv5;0×47f…” attribute to the LDAP records, and populate the Kerberos database on the Apple server with corresponding entries for your iCal users.
Maybe Kerberos has nothing to do with it though, and I’m misremembering… I would start by observing the Sun LDAP access logs while you attempt to authenticate an external user for iCal service. Note whether it’s looking up authAuthority. I’d also compare the contents of the apple attributes of a user in OD that has a calendar and has authenticated to the calendar server. I have in mind one of the attributes that hold XML data, like apple-mcxflags or apple-serviceslocator.
Good luck! I’d love to hear how it goes.
June 14th, 2008 at 9:55 pm
Patrick: also, see chefhomer’s comments above. He got authentication for iCal working, but ran into a different problem. I think the solution was:
“serveradmin settings teams:enableClearTextAuth = yes”
June 25th, 2008 at 2:14 pm
I am currently experimenting with the Directory.app but am getting a ‘Directory was unable to find any Open Directory servers.’ when trying to add records. Everything else works fine. I have traced this to the following LDAP query:
(&(|(objectclass=apple-configuration)(objectclass=organizationalunit))(|(cn=CollabServices)(ou=CollabServices)))
which i do not have in my ‘OD from scratch’ openldap on Debian. I suspect the missing part is within the apple-xmlplist attribute of the ou=CollabServices record within the cn=Config subtree. Can someone please paste their content from an ‘proper’ OD server?
TIA,
June 25th, 2008 at 2:19 pm
Never mind, I just created an empty record and now it is working
August 1st, 2008 at 11:38 am
Get ready this will be a long one. A few months back I posted that the teams server authentication worked, well for me, that is partially true. A newly created user in the Sun Directory with all the attribues and object classes that a local user would have, cannont create a weblog, but they can go to another users blog, log in and edit ANY blog on the system. Any user that is created locally, by local I mean in the apple directory. is subject to the appropriate security constructs.
I went back through my configuration steps and referenced the three articles here. I have tailed out my Sun Java Directory log files and looked at the searches that are being done, there is not much to the filter:
Attempting to create a weblog:
[31/Jul/2008:15:17:10 -0500] conn=419 op=98 msgId=99 - SRCH base=”dc=wichita,dc=edu” scope=2 filter=”(&(|(objectClass=posixAccount)(objectClass=inetOrgPerson)(objectClass=shadowAccount))(|(|(uid=g892k662))(|(cn=g892k662))))” attrs=”uid cn uid cn”
[31/Jul/2008:15:17:10 -0500] conn=419 op=98 msgId=99 - RESULT err=0 tag=101 nentries=1 etime=0
[31/Jul/2008:15:17:10 -0500] conn=419 op=99 msgId=100 - ABANDON targetop=NOTFOUND msgid=99
yet in the wikid/error.log I get
Failure: twisted.cred.error.UnauthorizedLogin: Bad username or password: g892k662
Attempting to edit a blog that is not my own: (long… more dialouge below…)
[31/Jul/2008:15:17:57 -0500] conn=419 op=100 msgId=101 - SRCH base=”dc=wichita,dc=edu” scope=2 filter=”(&(|(objectClass=posixAccount)(objectClass=inetOrgPerson)(objectClass=shadowAccount))(|(uidNumber=7003)))” attrs=”uidNumber uid cn gidNumber uidNumber”
[31/Jul/2008:15:17:57 -0500] conn=419 op=100 msgId=101 - RESULT err=0 tag=101 nentries=1 etime=0
[31/Jul/2008:15:17:57 -0500] conn=419 op=101 msgId=102 - ABANDON targetop=NOTFOUND msgid=101
[31/Jul/2008:15:17:57 -0500] conn=419 op=102 msgId=103 - SRCH base=”dc=wichita,dc=edu” scope=2 filter=”(&(|(objectClass=posixGroup))(|(gidNumber=14)))” attrs=”cn gidNumber gidNumber”
[31/Jul/2008:15:17:57 -0500] conn=419 op=102 msgId=103 - RESULT err=0 tag=101 nentries=0 etime=0
[31/Jul/2008:15:17:57 -0500] conn=419 op=103 msgId=104 - ABANDON targetop=NOTFOUND msgid=103
[31/Jul/2008:15:17:57 -0500] conn=419 op=104 msgId=105 - SRCH base=”dc=wichita,dc=edu” scope=2 filter=”(&(|(objectClass=posixGroup))(|(memberUid=f282c439)))” attrs=”cn gidNumber memberUid”
[31/Jul/2008:15:17:57 -0500] conn=419 op=104 msgId=105 - RESULT err=0 tag=101 nentries=0 etime=0
[31/Jul/2008:15:17:57 -0500] conn=419 op=105 msgId=106 - ABANDON targetop=NOTFOUND msgid=105
[31/Jul/2008:15:17:57 -0500] conn=419 op=106 msgId=107 - SRCH base=”dc=wichita,dc=edu” scope=2 filter=”(&(|(objectClass=posixAccount)(objectClass=inetOrgPerson)(objectClass=shadowAccount))(|(|(uid=unauthenticated))(|(cn=unauthenticated))))” attrs=”uidNumber uid cn gidNumber uid cn”
[31/Jul/2008:15:17:57 -0500] conn=419 op=106 msgId=107 - RESULT err=0 tag=101 nentries=0 etime=0
[31/Jul/2008:15:17:57 -0500] conn=419 op=107 msgId=108 - ABANDON targetop=NOTFOUND msgid=107
[31/Jul/2008:15:17:57 -0500] conn=419 op=108 msgId=109 - SRCH base=”dc=wichita,dc=edu” scope=2 filter=”(&(|(objectClass=posixAccount)(objectClass=inetOrgPerson)(objectClass=shadowAccount))(|(|(uid=f282c439))(|(cn=f282c439))))” attrs=”uidNumber uid cn gidNumber uid cn”
[31/Jul/2008:15:17:57 -0500] conn=419 op=108 msgId=109 - RESULT err=0 tag=101 nentries=1 etime=0
[31/Jul/2008:15:17:57 -0500] conn=419 op=109 msgId=110 - ABANDON targetop=NOTFOUND msgid=109
[31/Jul/2008:15:17:57 -0500] conn=419 op=110 msgId=111 - SRCH base=”dc=wichita,dc=edu” scope=2 filter=”(&(|(objectClass=posixGroup))(|(cn=com.apple.access_all_services)))” attrs=”cn gidNumber cn”
[31/Jul/2008:15:17:57 -0500] conn=419 op=110 msgId=111 - RESULT err=0 tag=101 nentries=0 etime=0
[31/Jul/2008:15:17:57 -0500] conn=419 op=111 msgId=112 - ABANDON targetop=NOTFOUND msgid=111
[31/Jul/2008:15:17:57 -0500] conn=419 op=112 msgId=113 - SRCH base=”dc=wichita,dc=edu” scope=2 filter=”(&(|(objectClass=posixGroup))(|(cn=com.apple.access_weblog)))” attrs=”cn gidNumber cn”
[31/Jul/2008:15:17:57 -0500] conn=419 op=112 msgId=113 - RESULT err=0 tag=101 nentries=0 etime=0
[31/Jul/2008:15:17:57 -0500] conn=419 op=113 msgId=114 - ABANDON targetop=NOTFOUND msgid=113
[31/Jul/2008:15:17:57 -0500] conn=419 op=114 msgId=115 - SRCH base=”dc=wichita,dc=edu” scope=2 filter=”(&(|(objectClass=posixAccount)(objectClass=inetOrgPerson)(objectClass=shadowAccount))(|(uidNumber=7003)))” attrs=”uidNumber uid cn gidNumber uidNumber”
[31/Jul/2008:15:17:57 -0500] conn=419 op=114 msgId=115 - RESULT err=0 tag=101 nentries=1 etime=0
[31/Jul/2008:15:17:57 -0500] conn=419 op=115 msgId=116 - ABANDON targetop=NOTFOUND msgid=115
[31/Jul/2008:15:17:57 -0500] conn=419 op=116 msgId=117 - SRCH base=”dc=wichita,dc=edu” scope=2 filter=”(&(|(objectClass=posixGroup))(|(gidNumber=14)))” attrs=”cn gidNumber gidNumber”
[31/Jul/2008:15:17:57 -0500] conn=419 op=116 msgId=117 - RESULT err=0 tag=101 nentries=0 etime=0
[31/Jul/2008:15:17:57 -0500] conn=419 op=117 msgId=118 - ABANDON targetop=NOTFOUND msgid=117
[31/Jul/2008:15:17:57 -0500] conn=419 op=118 msgId=119 - SRCH base=”dc=wichita,dc=edu” scope=2 filter=”(&(|(objectClass=posixGroup))(|(memberUid=f282c439)))” attrs=”cn gidNumber memberUid”
[31/Jul/2008:15:17:57 -0500] conn=419 op=118 msgId=119 - RESULT err=0 tag=101 nentries=0 etime=0
[31/Jul/2008:15:17:57 -0500] conn=419 op=119 msgId=120 - ABANDON targetop=NOTFOUND msgid=119
[31/Jul/2008:15:17:57 -0500] conn=419 op=120 msgId=121 - SRCH base=”dc=wichita,dc=edu” scope=2 filter=”(&(|(objectClass=posixGroup))(|(memberUid=_www)))” attrs=”cn gidNumber memberUid”
[31/Jul/2008:15:17:57 -0500] conn=419 op=120 msgId=121 - RESULT err=0 tag=101 nentries=0 etime=0
[31/Jul/2008:15:17:57 -0500] conn=419 op=121 msgId=122 - ABANDON targetop=NOTFOUND msgid=121
[31/Jul/2008:15:18:14 -0500] conn=419 op=122 msgId=123 - SRCH base=”dc=wichita,dc=edu” scope=2 filter=”(&(|(objectClass=posixAccount)(objectClass=inetOrgPerson)(objectClass=shadowAccount))(|(|(uid=g892k662))(|(cn=g892k662))))” attrs=”uid cn uid cn”
[31/Jul/2008:15:18:14 -0500] conn=419 op=122 msgId=123 - RESULT err=0 tag=101 nentries=1 etime=0
[31/Jul/2008:15:18:14 -0500] conn=419 op=123 msgId=124 - ABANDON targetop=NOTFOUND msgid=123
[31/Jul/2008:15:18:14 -0500] conn=419 op=124 msgId=125 - SRCH base=”dc=wichita,dc=edu” scope=2 filter=”(&(|(objectClass=posixAccount)(objectClass=inetOrgPerson)(objectClass=shadowAccount))(|(uid=g892k662)(cn=g892k662)))” attrs=”userPassword”
[31/Jul/2008:15:18:14 -0500] conn=419 op=124 msgId=125 - RESULT err=0 tag=101 nentries=1 etime=0
[31/Jul/2008:15:18:14 -0500] conn=419 op=125 msgId=126 - SRCH base=”dc=wichita,dc=edu” scope=2 filter=”(&(|(objectClass=posixAccount)(objectClass=inetOrgPerson)(objectClass=shadowAccount))(|(uid=g892k662)(cn=g892k662)))” attrs=ALL
[31/Jul/2008:15:18:14 -0500] conn=419 op=125 msgId=126 - RESULT err=0 tag=101 nentries=1 etime=0
[31/Jul/2008:15:18:14 -0500] conn=422 op=-1 msgId=-1 - fd=43 slot=43 LDAP connection from 156.26.180.77:49325 to 156.26.180.85
[31/Jul/2008:15:18:14 -0500] conn=422 op=0 msgId=1 - SRCH base=”" scope=0 filter=”(objectClass=*)” attrs=”supportedSASLMechanisms namingContexts dnshostname krbname”
[31/Jul/2008:15:18:14 -0500] conn=422 op=0 msgId=1 - RESULT err=0 tag=101 nentries=1 etime=0
[31/Jul/2008:15:18:14 -0500] conn=422 op=1 msgId=2 - BIND dn=”uid=g892k662,ou=People,dc=wichita,dc=edu” method=128 version=3
[31/Jul/2008:15:18:14 -0500] conn=422 op=1 msgId=2 - RESULT err=0 tag=97 nentries=0 etime=0
Has anyone tested this? Has anyone had this same expirence? What am I missing?
September 3rd, 2008 at 11:07 pm
This has been a great set of articles. Can’t wait for part-4. Any ideas when you will post?
Cheers
John