[sramdeen]

I created an _ldap_replicator entry in the passwordserver using mkpassdb: (I already had an _ldap_replicator user in my directory, but no entry in the PWS. If you don’t have either it’ll probably be easier to simply create the user using WGM)

[code]mkpassdb -b -u _ldap_replicator -p
[/code]
Set the password to the string after ‘credentials=’ in the syncrepl section of the file:

/etc/openldap/slapd_macosxserver.conf on the replica. e.g credentials=[b]updater374325646[/b]

find the slot ID of the new user:

[code]mkpassdb -dump
[/code]
e.g

slot 0030: 0x4ac623546b8b4567000000230000001e _ldap_replicator 08/24/2010 01:17:09 PM

take the slot ID and the public key of the PWS (obtained by mkpassdb -key) and create the authenticationauthority string:

;ApplePasswordServer;0x4ac623546b8b4567000000230000001e,1024 35
1424571524061015083254016898004018289433991726500019224615493370856703081327
62268977527666506917565988609023219075646958245279120071535875650486506288522
65148944512550427329967391154478653613168995376976846848073369002239852084735
40100483907088405638187142917101666429343681676619891172551685880553898864097
43 [email protected]:192.168.2.254

Pop that into the AuthenticationAuthority section using the inspector in WGM

[code]slapconfig -stopldapserver
slapconfig -startldapserver[/code]

on both the master and replica
and then monitor the slapd.log on both to see if the error persists. Check replication by creating a new user on the master, deleting a user on the master and editing a user on the master. All actions should immediately propagate to the replica(s)

Stu

[sramdeen]

just come across a similar problem. Think I’ve fixed it.

Could you check your opendirectory master and check to see if you have an _ldap_replicator user? You may have to enable the ‘show system users and groups’ in WGM.

Check their record using the inspector. What’s the contents of their ‘AuthenticationAuthority’?

Stu

[sramdeen]

I also had this same issue on a 10.5.8 server just now. It was hanging at the mkpassdb stage and therefore wasn’t getting onto the actual authauthority creation stage. I tried following the Apple instructions to the letter but it still didn’t work.

What I did instead was temporarily move mkpassdb to mkpassdb.apple and symlink /usr/bin/true to /usr/sbin/mkpassdb.

I ran all of the steps again and it completely successfully. I had a bunch of correct kerb authauthority records in my OD. I then deleted my symlink and ran mkpassdb -kerberize manually.

As a last step I ran sso_util to configure the server for all services and tested it. Worked like a charm! Kerb on the clients is now working a treat.

Hope this might help others in the same situation.

Cheers

Stu

[sramdeen]

Yes, you can. But you REALLY don’t want to use CIFS/SMB on the Mac side of things.

You would be much better installing ExtremeZIP on the windows server(s) to provide native AFP connectivity to the Macs.

OR

Use the Mac server(s) and the SMB service to provide the home directories to the PC clients. You’ll have to repoint all of the users’ home directory paths to the Mac server (in their AD ‘profile’ tab). Seems to work well, especially in 10.5 Server and onwards.

[sramdeen]

a lot of it relevant to AFP in general, including Apple’s dodgy version:

http://www.grouplogic.com/resource-center/pdfs/ExtremeZ-IP-60-vs-SMB.pdf

Stu

[sramdeen]

I have had some good and some not so good experiences with this. After failing with Bombich’s script and binary I thought I’d hack something together myself.

The main problem I have come across is dealing with ADs where the users or even just a couple of users have spaces or special characters in their usernames.
Most of the sites where I have worked have a great nomenclature for usernames. Usually something like first initial and then surname, or the other way around. In the case of schools & colleges they usually prefix or suffix with the year of enrolment unless it’s a very small school.

I have had some ‘issues’ with the way that dscl reports group membership. I have found that if there are no usernames with spaces in a given group, the list of members will be returned, each separated by a space. For groups that have usernames with spaces, the usernames are separated by a new line. This isn’t the end of the world and can be adjusted for in the script. Perhaps a better fix would be to output dscl to a plist and then read the plist. I’ll have to try it when I have time.

However, what I can’t seem to get working properly is augments for users that have a username somewhere in the AD with a space in it.

For example, if I perform a `dscl /Search read Groups/all\ staff GroupMembership` I might get something like this:

GroupMembership:
DOMAIN\shalom cohen
DOMAIN\richard brown

However, looking at the user record for these users indicates that their ‘real’ username does not have any spaces in it:

dscl /Search read Users/shalom\ cohen

dsAttrTypeNative:sAMAccountName: scohen

but:

RecordName:
scohen
shalom cohen
[email protected]
DOMAIN\scohen
DOMAIN\shalom cohen
Shalom Cohen

I’m not sure why a dscl query of a group is returning members of the group using their second ‘RecordName’ rather than their first or even the sAMAccountName.

Anyhow, if you can account for that (I have used some ldapsearch routines in this particular version of the script to search for users in a given OU and return the sAMAccountName), you might be able to modify this script for your own usage:

[code]
#!/bin/bash
# Stuart Ramdeen, Toucan Computing Ltd. 2009.
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
APPLESERVER=”gsxserve01.domain.lea.sch.uk”
APPLESERVERSHARE=”machomes”
APPLESERVERPATHTOSHARE=”/Volumes/data/”
DIRADMIN=”diradmin”
DIRADMINPW=”PASSWORD”

IFS=’
‘

y2002=”$(ldapsearch -x -LLL -H ldap://gsdc01.domain.lea.sch.uk -b ‘OU=Y2002,OU=Students,DC=domain,DC=lea,DC=sch,DC=uk’ -D “CN=macadmin,CN=Users,DC=domain,DC=lea,DC=sch,DC=uk” -w PASSWORD sAMAccountName|grep sAMAccountName|awk ‘{print $2}’)”
y2003=”$(ldapsearch -x -LLL -H ldap://gsdc01.domain.lea.sch.uk -b ‘OU=Y2003,OU=Students,DC=domain,DC=lea,DC=sch,DC=uk’ -D “CN=macadmin,CN=Users,DC=domain,DC=lea,DC=sch,DC=uk” -w PASSWORD sAMAccountName|grep sAMAccountName|awk ‘{print $2}’)”
y2004=”$(ldapsearch -x -LLL -H ldap://gsdc01.domain.lea.sch.uk -b ‘OU=Y2004,OU=Students,DC=domain,DC=lea,DC=sch,DC=uk’ -D “CN=macadmin,CN=Users,DC=domain,DC=lea,DC=sch,DC=uk” -w PASSWORD sAMAccountName|grep sAMAccountName|awk ‘{print $2}’)”
y2005=”$(ldapsearch -x -LLL -H ldap://gsdc01.domain.lea.sch.uk -b ‘OU=Y2005,OU=Students,DC=domain,DC=lea,DC=sch,DC=uk’ -D “CN=macadmin,CN=Users,DC=domain,DC=lea,DC=sch,DC=uk” -w PASSWORD sAMAccountName|grep sAMAccountName|awk ‘{print $2}’)”
y2006=”$(ldapsearch -x -LLL -H ldap://gsdc01.domain.lea.sch.uk -b ‘OU=Y2006,OU=Students,DC=domain,DC=lea,DC=sch,DC=uk’ -D “CN=macadmin,CN=Users,DC=domain,DC=lea,DC=sch,DC=uk” -w PASSWORD sAMAccountName|grep sAMAccountName|awk ‘{print $2}’)”
y2007=”$(ldapsearch -x -LLL -H ldap://gsdc01.domain.lea.sch.uk -b ‘OU=Y2007,OU=Students,DC=domain,DC=lea,DC=sch,DC=uk’ -D “CN=macadmin,CN=Users,DC=domain,DC=lea,DC=sch,DC=uk” -w PASSWORD sAMAccountName|grep sAMAccountName|awk ‘{print $2}’)”
y2008=”$(ldapsearch -x -LLL -H ldap://gsdc01.domain.lea.sch.uk -b ‘OU=Y2008,OU=Students,DC=domain,DC=lea,DC=sch,DC=uk’ -D “CN=macadmin,CN=Users,DC=domain,DC=lea,DC=sch,DC=uk” -w PASSWORD sAMAccountName|grep sAMAccountName|awk ‘{print $2}’)”
y2009=”$(ldapsearch -x -LLL -H ldap://gsdc01.domain.lea.sch.uk -b ‘OU=Y2009,OU=Students,DC=domain,DC=lea,DC=sch,DC=uk’ -D “CN=macadmin,CN=Users,DC=domain,DC=lea,DC=sch,DC=uk” -w PASSWORD sAMAccountName|grep sAMAccountName|awk ‘{print $2}’)”
media=”$(ldapsearch -x -LLL -H ldap://gsdc01.domain.lea.sch.uk -b ‘OU=Media,OU=Students,DC=domain,DC=lea,DC=sch,DC=uk’ -D “CN=macadmin,CN=Users,DC=domain,DC=lea,DC=sch,DC=uk” -w PASSWORD sAMAccountName|grep sAMAccountName|awk ‘{print $2}’)”

if [[ “$1″ ]] ; then
users=”$1”
else
users=($media $y2002 $y2003 $y2004 $y2005 $y2006 $y2007 $y2008 $y2009)
fi

#echo “${users[@]}”

for u in “${users[@]}” ; do
if [[ `dscl /Search read /Augments/Users:”$u” 2>/dev/null |grep -c RealName` -eq 0 ]] ; then
echo “####################################################################”
echo creating augmented records for user “$u”
dscl -u “$DIRADMIN” -P “$DIRADMINPW” /LDAPv3/127.0.0.1 create /Augments/Users:”$u” ;
dscl -u “$DIRADMIN” -P “$DIRADMINPW” /LDAPv3/127.0.0.1 create /Augments/Users:”$u” RealName “$u” ;
dscl -u “$DIRADMIN” -P “$DIRADMINPW” /LDAPv3/127.0.0.1 create /Augments/Users:”$u” PrimaryGroupID 20 ;
dscl -u “$DIRADMIN” -P “$DIRADMINPW” /LDAPv3/127.0.0.1 create /Augments/Users:”$u” GeneratedUID `uuidgen` ;
dscl -u “$DIRADMIN” -P “$DIRADMINPW” /LDAPv3/127.0.0.1 create /Augments/Users:”$u” ServicesLocator “(null):(null):calendar” ;
dscl -u “$DIRADMIN” -P “$DIRADMINPW” /LDAPv3/127.0.0.1 create /Augments/Users:”$u” UniqueID `id -u “$u”` ;
dscl -u “$DIRADMIN” -P “$DIRADMINPW” /LDAPv3/127.0.0.1 create /Augments/Users:”$u” UserShell /usr/bin/false ;
dscl -u “$DIRADMIN” -P “$DIRADMINPW” /LDAPv3/127.0.0.1 create /Augments/Users:”$u” HomeDirectory “afp://”$APPLESERVER”/”$APPLESERVERSHARE”$u” ;
dscl -u “$DIRADMIN” -P “$DIRADMINPW” /LDAPv3/127.0.0.1 create /Augments/Users:”$u” NFSHomeDirectory “/Network/Servers/”$APPLESERVER””$APPLESERVERPATHTOSHARE””$APPLESERVERSHARE”/$u” ;
echo created record for user “$u”
echo “####################################################################”

else
echo augment exists for user “$u”, skipping
fi
done

echo “#######################
#You will need to issue a ‘sudo killall DirectoryService’ and ‘sudo createhomedir -s’ if new augments have been created
#######################”
exit 0

[/code]

Note the createhomedir bit at the end. I have had very mixed results using createhomedir -s after creating the augments. Even after a restart of DS or a complete server reboot, createhomedir doesn’t pick up all augmented users.
I have also had to knock up a quick script to query the DS for augments and then check the ‘machomes’ folder to see if a home folder for that user exists. If it doesn’t, create it.

Please feel free to suggest any improvements.

Stu

[sramdeen]

no, you wouldn’t even need to do that. Sorry, perhaps my explanation wasn’t clear. For your setup you would edit the synchronisation URL on a machine group basis, meaning that all users logging in to a Mac in that list had their sync URL settings applied to them so that their home dir effectively lives on the Mac server. The users record on the AD is not touched at all – the AD doesn’t know that the user’s home is on a Mac server, that’s down to the Mac client and OS X Server.

the only real thing you need to decide is whether or not you want mobile accounts with synchronisation (users almost always sit at the same machines and they are hard-wired) or live network homes to the Mac server (users move around a lot, you have laptops running wirelessly). The other benefit of synchronised homes is that things like Adobe CS and M$ stuff plays better compared to them being run from a ‘live’ network home directory, as to the running application the home directory is a local one.

The former is where Synchronisation URL comes into play, the latter is simply a case of augmenting the users’ AD record with an OD one providing certain bits of info for the client (Home directory location being the obvious one).

Stu

[sramdeen]

It is most definitely possible, but it’s not really something that’s publicly documented by Apple.

What you can do is manage the ‘Synchronisation URL’ setting in the mobile account MCX for a given workgroup. From the description:

[quote]URL of the network home used for home sync. Only setable for mobile account creation. The string “%@” will be substituted with the user record name before use. Example: afp://myserver.apple.com/Users/BuildingA/%@ .[/quote]

I have a setup so that:

 AD users can log in to the Macs with their normal everyday username and password and have a homedir located live to the mac server (using augmented records, as described here http://209.85.229.132/search?q=cache:1cpVgeTTKs0J:developer.apple.com/releasenotes/MacOSXServer/RN-DirectoryServicesSession549/index.html+extending+directory+services&cd=1&hl=en&ct=clnk&client=safari – God bless ’em, they’ve broken the link)
 If users want to use iMovie or FCE, they log in with their ‘movie’ username assigned to them/their group. This user account is also in AD, but it is in a OD workgroup that has its Synchronisation URL set, so that the homedir sync up and down to/from the xserve in order to make video apps play nicely.

Let me know if you have any questions.

Stu

[Author]

Posts