Howto read a specific users encrypted password

  • Thread starter Thread starter Jesper
  • Start date Start date
J

Jesper

Hi
Is it possible to read and write the encrypted password of a specific user.
I need it for password syncronization between 2 DC's.

Regards,
Jesper
 
Is it possible to read and write the encrypted password of a specific
user.
Click to expand...

It must be possible since ADMT now manages it, but it's
not probably hard to find a tool to do it.

IF these two DCs are in the same domain you do NOT need this
for syncronization -- they do that anyway.

IF they are in different domains, they don't synchronize anyway so
you got some splainin' to do.
 
Hi Herb

The structure of my AD is that I have 2 autonomous domains (a1 and a2) and a
root domain (rootDC). All the users on rootDC have to be available on a1 and
a2, but (here's the tricky part) the admins of a1 and a2 wants to be able to
place the users in different OU's. As an example the user "mrtest" has the
following ldap-style placements.



a1:

LDAP://cn=mrtest,ou=staff,dc=a1,dc=dk

a2:

LDAP://cn=mrtest,ou=student,dc=a1,dc=dk

rootDC:

LDAP://cn=mrtest,ou=newusers,dc=a1,dc=dk



Since it isn't possible to have a user placed in different OU's the users
must be independent of each other (and their passwords will therefore not be
synchronized).

My idea was that if I could read the encrypted password on the rootDC and
write this on the ac1 and ac2 I could synchronize the passwords easily. I
know that Microsoft makes a program that does this synchronization but it
costs $25k/cpu (in my case that would be $100k).



However since ADMT is able to read the passwords and migrate them (write) it
must be possible to do so yourself.

Do you know if it is possible only to migrate the users password using ADMT
?





Regards

Jesper
 
microsoft.public.win2000.security news group, Jesper
Hi Herb

The structure of my AD is that I have 2 autonomous domains (a1 and a2) and a
root domain (rootDC). All the users on rootDC have to be available on a1 and
a2, but (here's the tricky part) the admins of a1 and a2 wants to be able to
place the users in different OU's. As an example the user "mrtest" has the
following ldap-style placements.



a1:

LDAP://cn=mrtest,ou=staff,dc=a1,dc=dk

a2:

LDAP://cn=mrtest,ou=student,dc=a1,dc=dk

rootDC:

LDAP://cn=mrtest,ou=newusers,dc=a1,dc=dk
Click to expand...

Sorry, but this doesn't make any sense at all. What do you mean by
"autonomous" domains? Either a1 and a2 are child domains of the root
domain, or they are not, in which case all 3 domains are forest root
domains.

If the former, then why in the world are you creating 3 separate
accounts for the same user? If the latter, then you seriously need to
rethink your AD design.
 
----cut-----
Sorry, but this doesn't make any sense at all. What do you mean by
"autonomous" domains? Either a1 and a2 are child domains of the root
domain, or they are not, in which case all 3 domains are forest root
domains.
Click to expand...



What I mean with "autonomous domains" is, that the admins of these domains
are completely independent; they are not managed by what I called the
rootDC.

They (a1 and a2) cannot be child domains of rootDC, since the admins of a1
and a2 wants to be able to move ALL users around in different OU's (when a
child domain inherits users/password from its root domain, then the users
are bound to certain OU's, the OU's where they are placed in the rootDC).



I guess that we could call a1 and a2 root domains, since they have nothing
in common with rootDC, except that a user that is able to log on to rootDC
must also be able to log on to a1 and a2 - and if the users changes his
password on rootDC, his password must also change on a1 and a2 (within a
certain time limit for ex. 15 minutes).



a1<-rootDC(password changes)->a1
 
microsoft.public.win2000.security news group, Jesper
----cut-----




What I mean with "autonomous domains" is, that the admins of these domains
are completely independent; they are not managed by what I called the
rootDC.

They (a1 and a2) cannot be child domains of rootDC, since the admins of a1
and a2 wants to be able to move ALL users around in different OU's (when a
child domain inherits users/password from its root domain, then the users
are bound to certain OU's, the OU's where they are placed in the rootDC).



I guess that we could call a1 and a2 root domains, since they have nothing
in common with rootDC, except that a user that is able to log on to rootDC
must also be able to log on to a1 and a2 - and if the users changes his
password on rootDC, his password must also change on a1 and a2 (within a
certain time limit for ex. 15 minutes).



a1<-rootDC(password changes)->a1
Click to expand...

So you have 3 totally separate domains and a person will wind up having
3 totally separate accounts, one in each domain? No offense, but this is
a totally whacked out design and really defeats the whole purpose of
Active Directory. By going this route, you've at list tripled the amount
of management required. What is the business reason behind this design?

My strong advice would be to completely rethink this design. Perhaps you
should engage a consultant with extensive AD experience.

In any event, you might want to have a look at http://www.psynch.com/
 
So you have 3 totally separate domains and a person will wind up having
3 totally separate accounts, one in each domain? No offense, but this is
a totally whacked out design and really defeats the whole purpose of
Active Directory. By going this route, you've at list tripled the amount
of management required. What is the business reason behind this design?
Click to expand...

I know that it's not in the spirit of the AD structure but the way that I
see this, it's the only posibillity if I want the OU freedom I was talking
about. If the two different domains (a1 and a2) want 2 different GPOs on the
same user then they have to be in seperate OU's.
My strong advice would be to completely rethink this design. Perhaps you
should engage a consultant with extensive AD experience.

In any event, you might want to have a look at http://www.psynch.com/
Click to expand...

I already know this program - but thanks anyway.
Regards,
Jesper
Click to expand...
 
What I mean with "autonomous domains" is, that the admins of these domains
are completely independent; they are not managed by what I called the
rootDC.

They (a1 and a2) cannot be child domains of rootDC, since the admins of a1
and a2 wants to be able to move ALL users around in different OU's (when a
child domain inherits users/password from its root domain, then the users
are bound to certain OU's, the OU's where they are placed in the rootDC).
Click to expand...

Then you need three domains. Or new admins for a1 and a2 who aren't
so power hungry. Is there a *legitimate* reason they need to move the
users to different OU's? Something they can't handle in a normal
managment process?
I guess that we could call a1 and a2 root domains, since they have nothing
in common with rootDC...
Click to expand...

You don't "call" them root domains, they *are* forest roots. Period.
They're not child domains, so they have to be roots.
except that a user that is able to log on to rootDC
must also be able to log on to a1 and a2 - and if the users changes his
password on rootDC, his password must also change on a1 and a2 (within a
certain time limit for ex. 15 minutes).
Click to expand...

Can you say "yuck"? This is against every single reason you create
networks, domains and trusts. And three times the work.

And yes, you *seriously* need to rethink the design. At the very
least, use trusts as appropriate.

Jeff
 
microsoft.public.win2000.security news group, Jesper
I know that it's not in the spirit of the AD structure but the way that I
see this, it's the only posibillity if I want the OU freedom I was talking
about. If the two different domains (a1 and a2) want 2 different GPOs on the
same user then they have to be in seperate OU's.
Click to expand...

Why would you need 2 different GPOs to be applied to the same user
account? You still haven't explained any rational business need for the
AD design you've come up with. Perhaps if you provided more detail, one
of could help you out. Chances are you can do what you want to with a
normal forest design.
 
Ok, here goes - from scratch:

The business (a school) consists of ~10 computerrooms (CRs), each CR (in a
seperate building) has its own domain, DC (CR_DC) and administrators. All
the users ~5k (students) have to be able to login, in all the CRs (their
personal files are placed on some massive Unix-fileservers, which are
smb-mounted at login) - all these CRs are either *nix or Windows. TheWindows
rooms are currently running totally independent, each user has to apply for
a password at the local admin - thats where the problem is (no problem with
*nix, the shadowfile is distributed). I have made a system that syncronizes
password from Unix to Windows (if a users password is changed in unix, then
within 5 minutes its changed in windows, on the forestDC).

This is what I expected:
- The forestDC is a win2003 server, the CR_DC are win2k/win2003 servers
- A userdatabase (userDB) is maintained on forestDC.
- Each CR_DC has access to the userDB.
- The admins of a CR_DC, can add any user to their own local CR_DC groups.
- The admins of a CR_DC, has to be able ad GPO to users.
- The admins of a CR_DC, must not be able to change the forestDC's users
password, group membership (except the local one), this is all controlled
from the top.

That's all if I drop the (OU thing)

Regards,
Jesper
 
Ok, here goes - from scratch:

The business (a school) consists of ~10 computerrooms (CRs), each CR (in a
seperate building) has its own domain, DC (CR_DC) and administrators. All
the users ~5k (students) have to be able to login, in all the CRs (their
personal files are placed on some massive Unix-fileservers, which are
smb-mounted at login) - all these CRs are either *nix or Windows. TheWindows
rooms are currently running totally independent, each user has to apply for
a password at the local admin - thats where the problem is (no problem with
*nix, the shadowfile is distributed). I have made a system that syncronizes
password from Unix to Windows (if a users password is changed in unix, then
within 5 minutes its changed in windows, on the forestDC).

This is what I expected:
- The forestDC is a win2003 server, the CR_DC are win2k/win2003 servers
- A userdatabase (userDB) is maintained on forestDC.
- Each CR_DC has access to the userDB.
- The admins of a CR_DC, can add any user to their own local CR_DC groups.
- The admins of a CR_DC, has to be able ad GPO to users.
- The admins of a CR_DC, must not be able to change the forestDC's users
password, group membership (except the local one), this is all controlled
from the top.

That's all if I drop the (OU thing)
Click to expand...

Unless I'm misunderstanding this, a single forest with child domains
would handle this, wouldn't it?

Jeff
 
Maybe what he needs is LOOPBACK GPO processing if the user
logs onto a machine from a machine in one of the other domains.

He may not realize that GPOs are only processed for ACTUAL LOGONS,
not mere "authentication" when access resources remotely.
 
Hi Herb and Paul
I just figured out how to solve my problem - security groups, solves all my
problems (don't know why I haven't noticed that before). Thanks for all your
help/response.

Regards
Jesper


Herb Martin said:
Maybe what he needs is LOOPBACK GPO processing if the user
logs onto a machine from a machine in one of the other domains.

He may not realize that GPOs are only processed for ACTUAL LOGONS,
not mere "authentication" when access resources remotely.

--
Herb Martin
Paul Adare - MVP - Microsoft Virtual PC said:
microsoft.public.win2000.security news group, Jesper
Click to expand...
that
I
Click to expand...
on
Click to expand...
 
Hi Herb and Paul
I just figured out how to solve my problem - security groups, solves all my
problems (don't know why I haven't noticed that before). Thanks for all your
help/response.
Click to expand...

We knew that <grin> but that is not what you asked.

Sometimes it's better to tell us what you really want, rather
than describe exactly where you are stuck trying to achieve
that real goal.

Glad you figured it out -- to summarize:

OUs are NOT security principles -- they cannot be used to
grant access (or deny it) directly.

Users, Computers, and especially GROUPS are "security
principles" -- you use them to grant and deny access to
resources or to grant rights.
 
Back
Top