Matt, you don't have to do this manually.... your users all have the
same RSA keys... it's one find and replace on the entire ldif file...
If you've still got your original ldif file it's at most a 10 minute
proceedure to set your machine back to standalone, set it back up as
an OD master, get the RSA key, mod the ldif file, re-import and merge
the pws db again....
Cheers,
Andrina
On 11-Aug-05, at 2:50 PM, Matt Richard wrote:
Hi, Andrina,
I've been in communications with Apple on this, and they're
generally in agreement with what you have said in your article.
I submitted a bug (# 4203727), and Apple has been able to recreate
the problem. So it's not just my data (which I feared at first),
it's a general issue with the procedures which Apple (and you) have
documented.
There's possibly two authAuthority entries for each user: PWS and
Kerberos. The PWS entry seems to always wrap the same in the ldif
file, but the Kerberos entry always wraps differently depending on
the length of the uid. So there might be some issues with the copy/
paste method, but if this can be done on live data after it has
been imported into LDAP, we should be able to get around that.
Is wrapping an issue when using LDIF imports? I guess I could
experiment to find out.
I can't do a manual copy/paste for all 6,000 users in my OD
database. A guy at Apple is currently working on a script which
will do this conversion on a 10.4 server after I do the upgrade
procedures. I'm working on one in parallel, so we'll see who gets
done first. But there's no doubt that other Apple customers will
come across this same problem, so Apple will need a solution for them.
Thanks for the update, this will help anyone else who has
experienced problems as well.
-Matt
Just in addition to this - I've updated the article on afp548
today.... the update should help with your issues...
Cheers,
Andrina
On 29-Jul-05, at 12:00 PM, Andrina Kelly wrote:
Hey Matt,
So a couple ideas to try - I assume you're looking to get your
new machine going with the same IP and hostname, yes?
Try copying the contents of /var/db/authserver from your 10.3.9
box and after setting up your 10.4 OD master, replace the
contents of /var/db/authserver with your copied contents rather
than doing a mergedb or mergeparent.
You may need to copy the AuthenticationAuthority from the admin
account of your 10.3.9 server into the AuthenticationAuthority of
your 10.4 diradmin user.
Another thought, although you said you had issues with the 10.3.9
- 10.4 straight upgrade - perhaps try the upgrade, backup the OD
info on 10.4, then try importing that 10.4 backup onto a clean
10.4 machine....
Cheers,
Andrina
On 29-Jul-05, at 10:15 AM, Matt Richard wrote:
Hi,
I've been preparing for months to move my OD accounts from a set
of 10.3 servers to a set of 10.4 servers. I much prefer fresh
installs over upgrades whenever possible and this looked like a
good opportunity. I regularly tested this procedure in a test
environment so that I knew it would work once I had the
opportunity. I even had Apple fix a few bugs for me that I
found along the way.
I have a script which does the backup every night, so I just had
to do the restore on a new server.
Yesterday, the day finally came when I would migrate my OD
servers from 10.3.9 to 10.4. I used Carbon Copy Cloner to keep
a close backup of each OD server before wiping the hard drives
and installing a clean 10.4 Server system.
However once I imported my LDAP and Password Server information,
none of the users could authenticate. I tried importing several
times, with different variations, but nothing would work. I
tried restoring the 10.3.9 system on the OD master and then
upgrading to 10.4, and I ran into worse problems with slapd
crashes (which I might address another time). So I had to
revert back to 10.3.9 on my OD servers.
Today I tried again, in my test environment and it worked. I
discovered that the test environment, even though it is running
as an OD master, is forwarding Password Server authentication
requests to my real (not test) OD Master.
It seems to me that the user records are somehow tied to a
specific instance of a Password Server database. If I install a
new Password Server instance, even at the same address, users
cannot authenticate against it.
Does this make any sense?
Does anyone have any helpful hints for me?
Thanks,
Matt
--
Matt Richard
Access and Security Coordinator
Computing Services
Franklin & Marshall College
email@hidden
(717) 291-4157
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macos-x-server/email@hidden
This email sent to email@hidden
