NIS Server on Windows 2003 R2 - Password syinchronizing

[Marco De Rosa]

I had SFU 3.5 Nis Server up and Working on a W2K3-SP1 Domain controller. I
had about 700 users with UNIX attributes in the msSFU fields. Everything was
working smoothly.

Then I had to deploy R2 on this server. This is a DC so I followed
instructions: ADPREP on the forest, setup R2, uninstall SFU 3.5, add R2 NIS
server.

First surprise:

- new UNIX users get their UNIX informations (GECOS, shell, ID,
GID, ecc) in new RFC 2307 attributes, and this is correct. The old 700 UNIX
users have their UNIX attributes in the old msSFU attributes. Well I can't
believe that MS didn't think about this problem when upgrading from SFU35 to
R2!! So I had to write an LDIF script to copy attributes values for every
users and groups. Problem solved.

Second surprise:

- Now (almost) everything works. I create a user, assign UNIX
informations, they go in the right RFC attributes, NIS maps are distributed
correctly. The problem is that UNIX passwords are NOT synchronized with
Windows passwords. In SFU35 when a use was created, it got a standard
password (ABCD!efgh12345$67890). Then, the first time users changed their
password in Windows (or an Administrator reset it) the UNIX password was
synchronized in the msSFU30password field. In R2 this synchronization should
occur in the UnixUserPassword field. But it doesn't. I tried to change it
from Windows, to reset it in the "Active Directory Users and Computers" mmc.
It doesn't work. The old msSFU30password stays empty, the new
UnixUserPassword stays with "ABCD!efgh12345$67890". This way the NIS server
is pretty useless.

I tried everything: uninstall NIS server, reinstall it, and recreate
configurations. The problem is still there.

Any advice?

Thanks

Marco De Rosa

[BerkHolz, Steven]

Please provide the group your script.
I was about to do the same thing today.

--
--
Steven

May you have the peace and freedom that come from abandoning all hope of having a better past.
--- - --- - - - - - - - -- - - - --- - ------ - - --- - - -- - - - -- - - -
"Marco De Rosa" <der...@itc.it> wrote in message news:uzXGJkK...@TK2MSFTNGP12.phx.gbl...

[Marco De Rosa]

Hi Steven,

I did an export of all users and groups (just the needed attributes) in the
AD using LDIFDE.
Then, using two PERL scripts, I created two LDIF files: one for groups and
and one for users.

The first PERL script reads the values of the old groups attributes from
the export file and write an LDIF file like this, with a block for every
group:

----------------------------------------
#groups
dn: CN=xxx,OU=yyy,DC=mycompany,DC=com
changetype: modify
replace: GidNumber
UidNumber:115
-
----------------------------------------

The second PERL script reads the values of the old users attributes from the
export file and write an LDIF file like this, with a block for every user:

----------------------------------------
#users
dn: CN=xxx,OU=yyy,DC=mycompany,DC=com
changetype: modify
replace: UidNumber
UidNumber:15000
-

replace: GidNumber
GidNumber:115
-

replace: gecos
gecos:test user
-

replace: UnixHomeDirectory
UnixHomeDirectory:/home/test
-

replace: LoginShell
LoginShell:/bin/nologin
-

replace: UnixUserPassword
UnixUserPassword:123ERT3456
----------------------------------------

Of course the values of the attributes (and the DN) change for very block.

Then, using LDIFDE, I imported the two LDIF files into AD.
Please take care when you import!!! Do some tests with a test user before
the real bulk import!!

You can use PERL or the language of your choice to analyze and create the
LDIF files.

Good luck

Marco

["Martin v. Löwis"]

Marco De Rosa wrote:
> - Now (almost) everything works. I create a user, assign UNIX
> informations, they go in the right RFC attributes, NIS maps are distributed
> correctly. The problem is that UNIX passwords are NOT synchronized with
> Windows passwords.

Did you install password synchronization in R2? Did you do that on every
domain controller?

Regards,
Martin

[Marco De Rosa]

Martin, why should I do that? From the MS site:

"Password Synchronization helps integrate Windows and UNIX networks by
simplifying the process of maintaining secure passwords in both
environments. Instead of maintaining separate passwords for Windows and UNIX
accounts or having to remember to change passwords, whenever a user's
password is changed on a Windows-based computer or domain that has Password
Synchronization, the password is automatically changed on every UNIX host
for which the user has an account. Password Synchronization can also be
configured to change the user's Windows password when the user's UNIX
password is changed.

When Password Synchronization is configured for Windows-to-UNIX
synchronization and a password is changed on a Windows-based computer
running Password Synchronization, the Password Synchronization service
determines whether the user's password is to be synchronized on UNIX
computers. If it is, the service encrypts the password and sends it to the
Password Synchronization daemon on each computer with which the
Windows-based computer is configured to be synchronized. The ssod daemon
then decrypts the password and changes the password on the UNIX host. If the
UNIX host is an NIS master server and it is configured to do so, the daemon
also runs make to propagate the password change throughout the NIS domain."

I just want the password changed on the Microsoft NIS server that I have on
one of my domain controllers. I just need to propagate the passwd map to a
couple of UNIX hosts where I have a secondary NIS server. These are so old
that I can't use Kerberos authentication and, for several reasons, I can't
upgrade.

In the W2K3-Sp1 it worked like a charm, and Password Synchronization was not
installed.

BTW, I tried to install PS on the same DC where NIS is installed. It did not
work. Same result.

Regards

Marco

["Martin v. Löwis"]

Marco De Rosa wrote:
[Why do I have to run password synch on all domain controllers]

> Martin, why should I do that? From the MS site:

...

> When Password Synchronization is configured for Windows-to-UNIX
> synchronization and a password is changed on a Windows-based computer
> running Password Synchronization,

My understanding is this: if a user changes the password on Windows
on a workstation (through the GINA login window), the workstation
picks an arbitrary domain controller to perform the password change.

Now, *that* domain controller must be "a Windows-based computer
running Password Synchronization". As the client picks an arbitrary
DC, this will sometimes work, and sometimes it won't. To make
it work reliably, you need to run Password Synchronization on all
domain controllers.

My understanding might be wrong; I'm not using password synch
myself.

Regards,
Martin

[Marco De Rosa]

Martin,

This is my understanding of the problem: NIS Server and Password
Synchronization Service should be two independent services.

Password Synchronization works like this:

- a service is installed on DCs to talk to UNIX workstations;

- a ssod deamon is installed on UNIX workstations;

- When Password Synchronization is configured for Windows-to-UNIX

synchronization and a password is changed on a Windows-based computer

running Password Synchronization, the Password Synchronization service
determines whether the user's password is to be synchronized on UNIX
computers. If it is, the service encrypts the password and sends it to the
Password Synchronization daemon on each computer with which the
Windows-based computer is configured to be synchronized. The ssod daemon
then decrypts the password and changes the password on the UNIX host. If the
UNIX host is an NIS master server and it is configured to do so, the daemon
also runs make to propagate the password change throughout the NIS domain.

I never used this service in W2K3-SP1 because I cannot install the ssod
deamon on the "old" UNIX boxes. NIS server on the DC worked in an
independent way. It changed the msSFU30Password attributes every time a user
changed its windows password. This way the NIS Server was able to propagate
an updated passwd map to the two "old" UNIX boxes. Now it should work in the
same way, just changing the UnixUserPassword attribute. But it doesn't.

I tried to install PS on the same DC where NIS Server is installed. I know
that having four DCs it should work one in four times, but it never worked.
I did a hundred tries with different PCs and also resetting the password
directly on the NIS DC. No way.

I think MS did something wrong. They did not think about moving attributes
either...

Thanks anyway.

Best regards

Marco

""Martin v. Löwis"" <mar...@v.loewis.de> wrote in message
news:43E7D11D...@v.loewis.de...

["Martin v. Löwis"]

Marco De Rosa wrote:
> - a service is installed on DCs to talk to UNIX workstations;

Correct: on *all* DCs. Microsoft is pretty clear about that.
See "Implementing Password Synchronization" in the SFU help
file:

# To synchronize Windows domain passwords, you must install Password
# Synchronization on all domain controllers for that domain. This will
# ensure that when a domain controller processes a password change
# request, the Password Synchronization service on that domain
# controller will be able to synchronize the new password with the
# appropriate UNIX hosts. For this reason, before you remove Password
# Synchronization from a domain controller, you should demote the domain
# controller to a member server to prevent password discrepancies
# between the Windows domain and the UNIX hosts.

> - a ssod deamon is installed on UNIX workstations;

That might not be necessary, if you use Server for NIS.
See "Synchronizing passwords with an NIS domain":

# If Server for NIS is acting as the master server for the NIS domain,
# no action is required to provide one-way password synchronization
# because whenever a Windows user's password is changed, Server for NIS
# automatically updates the UNIX password for NIS clients.

I wonder how that works, though: To change the Unix password in the NIS
map, you need the clear-text password. Now, the DC on which Server for
NIS runs might never see the clear-text password. So how can it change
the msSFU30Password attribute?

> I tried to install PS on the same DC where NIS Server is installed. I know
> that having four DCs it should work one in four times, but it never worked.
> I did a hundred tries with different PCs and also resetting the password
> directly on the NIS DC. No way.

That isn't really convincing, though: Even if you change the password on
the NIS DC, it might talk to a different DC to perform the change
(different from the one on which you invoked the action).

Regards,
Martin

[Marco De Rosa]

Hi Martin,

You were right. For the passwords to synchronize you need to install:

- AD NIS Server on one DC;

- Password Sync services on every DC;

- activate "Enable Windows to NIS (AD) Password Sync" on every DC;

- reboot every DC.

Then you just don't add any UNIX computer to the Password Synchronization
services and it works just for the AD NIS Server.

Problem solved.

Thanks!!

Marco

""Martin v. Löwis"" <mar...@v.loewis.de> wrote in message

news:43E85020...@v.loewis.de...

["Martin v. Löwis"]

Marco De Rosa wrote:
> Problem solved.
>
>
>
> Thanks!!

I'm glad it works now!

Martin