DNS works on Both TCP and UDP why?

In interview, I have been asked many times – on which protocol DNS works? I say: TCP and UDP both. They ask: why it works on both protocols…that’s it! I say: sorry cound’t answer this question but I know that it works on both protocols. Here is the answer I have retreived from many resources on the web. The answer is very simple: TCP is a connection-oriented protocol and it requires data to be consistent at the destination and UDP is connection-less protocol and doesn’t require data to be consistent or don’t need a connection to be established with host for consistency of data.

UDP packets are smaller in size. Can’t be greater then 512 bytes. So any application needs data to be transffered greter than 512 bytes uses TCP 

We often discuss why services use both the protocols i.e. TCP and UDP. These services can also realy on TCP instead of UDP because TCP is a connection-oriented protocol whereas UDP is connection-less! then why use UDP?

For example, DNS uses both TCP and UDP for valid reasons described below. Note that UDP messages are not larger than 512 Bytes and are trucncted when greater than this size. So DNS uses TCP for Zone transfer and UDP for name queries either regular (primary) or reverse. UDP can be used to exchange small information whereas TCP must be used to exchange information larger than 512 bytes. If a client doesn’t get response from DNS it must retransmit the data using TCP after 3-5 seconds of interval.

We all know that there shouldn’t be any inconsistency in DNS zones – to make this happen DNS always transfer Zone data using TCP because TCP is reliable and make sure zone data is consistent by transffering the full zone to other DNS servers who has requested the data.

Shouting more on this…

The problem occurs when Windows 2000 server and Advanced Server products uses Dynamic ports for all above 1023. In this case your DNS server should not be internet facing ie. doing all standard queries for client machines on the network. The router (ACLs) must permitted all UDP inbound traffic to access any high UDP ports for it to work.

Now talk about LDAP. It always uses TCP – this is true and why not UDP. because a secure connection is established between client and server to send the data and this can be done only using TCP not UDP. UDP is only used when finding a domain controller (Kerberos) for authentication.

Group Policy to close off all programs before backup runs.

Let’s say you want to implement a policy setting that can be used to close off all the programs running in computer.

Actually speaking this is not bit easy but you can deploy a script that can do your job at specifed time using Task Scheduler service.

To accomplish above you need the followings:

1. A startup or logon script.

2. tlist.exe to display list of processes running on the computer and kill.exe to kill the processes running except Windows defaults.

3. AT command to schedule the script at specified time.

You need to know the *process name* of the application you want to close or kill. You can use resource kit tool called “kill.exe* to close the process of an application. When you kill the process, application will be closed automatically.

You need to run a script using Group Policy which will run at 10.00 PM everyday. You can achieve using Task Scheduler  service or using AT command in a script. Deploy this script using Group Policy.

Files opened by network clients must also be closed in order to perform backup. You can use the command outlined here to close all opened files by network users.  

Please follow this article:

http://support.microsoft.com/?kbid=290585

If you don’t know what all applications clients are running then you need to use some kind of programming stuff which can identify and close the application. Likewise all running applications can be closed by killing the main process that is Explorer.exe. But if you kill explorer.exe then you need to re-run it in order to perfrom backup. Using some programming stuffs you can acheive this. Here is an example:

1. You create a script.
2. Use kill.exe in this cript to end PID of explorer.exe or kill this process.
3. Run a command again to re-start this process (explorer.exe) to lunch desktop and then perform backup.

Disaster recovery plan for Roaming Profiles (without clustering in effect).

Have you ever wondered? creating a disaster recovery plan for Roaming profiles without clustering. This is really interesting when someone wants to switch over Roaming profile in a network where one of DC is failing and other DCs are alive to serve the requests.

Scenario:

Let’s say you have two 100 client computers in your network and two domain controllers named: DC1 and DC2. All users have been configured with roaming profiles setup on DC1 and DC2. These users frequently log on to DC1 and switch over to DC2 in case of failure.

For some reasons, you want to create a disaster recovery plan for Roaming users – you want these users to switch over to DC2 and retreive their roaming profile from DC2 in case of DC1 failure.

Setup seems not so easy! but this is how you do it actually:

You need a startup script and deploy this script using Group Policy throughout the network.

This disaster recovery plan for romaing profiles can be designed by creating a Windows startup script. LOGONSERVER environment variable is common between these two DCs. You just need to set this in your script so that when script starts it should read the authentication server name and set in user’s property using LDIFDE tool.

You can see LOGONSERVER by typing SET command at command prompt. This tells by which DC this client was authenticated.

In the above scenario clients roaming profile are located at DC1.

1. Client starts

2. Netlogon finds a suitable domain controller for the client.

3. Sets the Environment variable: LOGONSERVER to the DC is about to authenticate client.

4. Startup script runs.

5. This script checks the path of Roaming profiles from the user’s property using LDIFDE tool.

6. Script pings the domain controller (let’s say client is configured to use romaing profiles on DC1 and DC2 is supposed to authenticate client in this regard.)

7. Script gets a “Request Timed Out” message from DC1.

8. Script assumes that this domain controller is not available on the network.

9. Then it takes the DC name from the LOGONSERVER environment variable and sets this LOGONSERVER in user’s property and in registry as well : \\DC2\profiles\%username%.

10. Netlogon passes control to Winlogon service.

11. Winlogon finally allows client to log on to computer.

12. Client logs on to computer. His profile path is checked and roaming profile is loaded from DC2 directly.

13. So in this case no failure is noticed.

Configuring Time Service

By default, only the first domain controller or so-called Root domain controller and finally so-called “PDC Emulator” is configured to be a Reliable Time Source.

If it doesn’t exist you need to create it to make it ReliableTimeSource for other client computers and domain controllers.

Let me explain something:

By default client machines use *default heirarchy” to synchronize time. Clients will only sync with their own domain controllers in the domain. This is default bahviour and by design and to keep time closer between all PCs.

PDC is the 2nd highest stratum. Client will try to sync time with their own domain controller *unless* specifically you specify to do so. Becuase PDC is configured an authoritative server by default. It is configured using *ReliableTimeSource” entry in registry.

Stratum:

1     External NTP time source
2     PDC emulator of the forest root domain
3     Domain controllers in the forest root domain or PDC emulators in child domains
4     Workstations and member servers in the forest root domain or domain controllers in child domains
5     Workstations and member servers in child domains

Computers choose a time source according to a specific order of preference. This order, from most preferred to least preferred. The following table displays the preferences for Selecting a Time Source:

Preference     Computer                                     Location      Reliability of Time Source
1     Parent domain controller                              In-site                      Reliable
2     Local domain controller                                In-site                      Reliable
3     Parent domain controller                              In-site                      Not reliable
4     Local PDC emulator                                      In-site                     Not reliable
5     Parent domain controller                               Out-of-site               Reliable
6     Local domain controller                                 Out-of-site               Reliable
7     Parent domain controller                               Out-of-site               Not reliable
8     Local PDC emulator                                      Out-of-site                Not reliable

There is nothing much you need to do with *ReliableTimeSource* entry in registry. Simply edit the value and set it to 1 to make it Reliable time source for all computers in your network.

Moreover, you can also configure your PDC or Root Domain Controller to sync with hardware as a source time server but it is recommended that you configure your PDC to sync with an external time source.

How to configure an Authoritative Time server in Windows 2000:
http://support.microsoft.com/kb/q216734/

How to delegate basic server administration to Junior Admins

 

Here is a complete list of articles for delegating controls to admins:

 

You can delegate permissions to junior Admins using MMC Taskpads.

How to use Adminpak.msi to install a specific server administration tool in Windows
http://support.microsoft.com/?kbid=314978

HOW TO: Delegate Administrative Authority in Windows 2000
http://support.microsoft.com/?kbid=315676

HOW TO: Create and Edit a Taskpad View in a Saved MMC Console in Windows 2000
http://support.microsoft.com/?kbid=321143

Default Security Concerns in Active Directory Delegation
http://support.microsoft.com/?kbid=235531

Delegate Control Wizard Cannot Be Used to Remove Groups or Users
http://support.microsoft.com/?kbid=229873

Administrative Tool Menu Is Sensitive to User’s Permissions
http://support.microsoft.com/?kbid=214739

In a Server 2003 domain, you can ignore the part about editing dssec.dat:

How To Delegate the Unlock Account Right
http://support.microsoft.com/?kbid=294952

A must read for Domain Administrators:

Design Considerations for Delegation of Administration in Active Directory

*Achieving Autonomy and Isolation with Forests, Domains, and Organizational Units*
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/addeladm.mspx

Using scripts you can set delegation on properties if you want:

Part 1
http://www.microsoft.com/technet/scriptcenter/topics/security/exrights.mspx

Part 2
http://www.microsoft.com/technet/scriptcenter/topics/security/propset.mspx

You can find security attributes for each object in Chapter -6 of *Inside Active Directory-Second Edition*
Here it is: An online version of this book.

http://www.readol.net/books/computer/Windows/Inside.Active.Directory.A.System.Administrators.Guide.Second.Edition/0321228480/ch04lev1sec3.html

Windows 2000/2003/XP computers may not load raoming profiles from a trusted domain.

You may face this issue. Sometimes member computers running Windows XP/2000/2003 may not load roaming profile from a trusted domain.

They should be able to log as long as the following conditions are true:

1. DNS settings are incorrect as suggested on some of your client computers.

2. Workstation service is not running on client computer.

3. Server service is not running on server.

4. Roaming Profile Share is not shared on server.

5. Permissions are not shared properly.

6. All Users and Default Users folders in Documents and Settings are missing if this is the first time user is logging on to this computer.

7. IPC$ share is missing on Client computer or Server.

 

You can find the exact cause by enabling the User Profile Debugging:

Enable User Profile Logging. You will know the problem.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;221833

Securing your network using Microsoft Windows DHCP

 

This article explains how you can secure a network running DHCP Service.

Microsoft has developed or added some security to DHCP Server by means of CLASS ID. You can use Class ID to secure a network for client who is part of the network or laptop users who recieve their IP Address from this DHCP Server on the network.

In DHCP Server you can configure the Class ID. When you configure Class ID you need to use the Same ID on all client machines so any DHCP Packet sent by the client can be understood by the DHCP server of that class. You set Class ID on client machines using *Ipconfig /setclassid* command.

Prevent computers gaining IP Address from DHCP Server if they are not authorized

A computer is authorized to obtain an IP Address on network only when it is configured with DHCP Class ID where you have implemented MS DHCP Server. This Class ID mechanism can be understood by MS DHCP Servers only.

We have secured our DHCP Network using *MS Class Options* (You can find this mechanism only in MS DHCP Implementation).

 
Client machines can’t get IP Address from any DHCP server available on the network  *IF* you have configured Class ID on client machines using *Ipconfig /setclassid* command. A DHCP packet will be dropped by DHCP server if *same Class ID* scope is not found on the network or MS DHCP server.

This is what happen when you implement Class ID on your network:

1. A computer plugs in your network.

2. DHCP client service starts and shouts on network to get an IP address (I assume this is a new computer and configured with Class ID).

3. DHCP Server goes throught its database or scopes check to see if it belongs to any Class ID scope, a simple scope or superscope if request is coming from different network id:

        a. If DHCP packet from client machine contains Class ID information, DHCP  
           Server goes through the Class ID Scopes. If it doesn’t find same class ID in
           its database, the DHCP packet is dropped off. Exit Loop. Next, if DHCP server
           finds the Class ID Scope, it leases out the IP address to client machine and
           Exit Loop.

        b. DHCP server goes to next condiation available that is *DHCP Scope for
           same subnet*. HERE DHCP server can lease out IP address from any scope
           if you haven’t configured client machine with Class ID. This is where DHCP
           Security is failing
. If DHCP server finds no other scope, DHCP packet is
           dropped off. Exit Loop.

        c. Next available condition is to check in *DHCP Superscope for same or other
            subnet* or if client doesn’t belong to same subnet. B condition applies  in this case.

3. After checking above conditions, DHCP Server finally decides to drop off packets therefore client obtains IP Address using APIPA (169.254.x.x). This makes client out of network or it can’t participate in network.

Restrict IPs to known MAC addresses (both static or DHCP) when the unauthorized machine has physical access to a NAM on the network.

 

1. Create a class on your network

2. Define a scope for these MAC systems only.

3. Create a unqiue Class ID for this scope.

4. Configure client machines using *Ipconfig /setclassid*. Set the Class ID which you have configured at DHCP Server.

Now when a DHCP server receive a packet from a client machine configuerd for the same Class ID, it will go through it’s scopes to check whether they belong to any Scope Class you have configured at DHCP server.
If DHCP Server finds Class Scope with same Class ID then this will lease IP address *ONLY* from this class regardless of the subnet clinet machines belong to. Condition No. A applies in this scenario.

NOTE:

1. This way you can secure your DHCP Server.

2. This only applies when client machines has configured to obtain IP address automatically from a DHCP Server. If client machine has configured with Static IP address then you can’t. You need to disable DHCP client service on client machine or unregister a DLL from their system or set permissions on registry on client machine so they can’t save informations.

3. You shouldn’t have any other Scope configured in your DHCP server without Class ID. If you do so DHCP server can lease out IP addresses from this scope if client request is coming without Class ID information or DHCP Packet from a client doesn’t contain Class ID. Either you can use scopes or Class ID but you can’t use both to implement this securtiy stuff. Check option A.B.C. described earliear in this article.

More here:  –
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/111527dc-1e28-4c25-ba20-67daeffa5d1b.mspx

DHCP Security: –

The following articles only address how you secure or detect rouge DHCP servers running in a network. It’s worth reading.

Part 1
http://www.windowsecurity.com/articles/DHCP-Security-Part1.html
Part 2: –
http://www.windowsecurity.com/articles/DHCP-Security-Part2.html

If your DHCP clients are all Windows 2000 or newer, then this will work pretty well for you.  If you have non-Windows 2000 or newer clients that need to use DHCP, this won’t work.

Class ID won’t work for:

Windows 9x/NT clients
PXE boot clients/other boot clients (Altiris Bootworks)
Non-Windows clients (Linux and Mac are most common)

Driver issue – Server not booting in Normal Mode

 

If you face any issue with Windows driver or third party driver, you can replace Safe Mode registry with Normal Mode to get things working properly. If you can boot into Safe Mode and then there are some chances to restore your computer using the Safe Mode registry data because pre-defined drivers and services in registry key for these modes are not changed when you install any application.

This is how you do it:

  1. Go to Safe Mode.
  1. Start Registry editor > navigate to the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal

  1. Save/Export this key to SafeBoot.reg file
  1. Next navigate to the following key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services

  1. Save/Export this to Services.reg.
  1. Now edit SafeBoot.reg in notepad or wordpad (make sure you disable word wrapping) > next

Find all the entries with:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal

and replace all with the following:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

  1. After replacing all entries save SafeBoot.reg file and double click on it.
  1. Now restart your computer in Normal Mode. It should boot.

Windows Log on and Log off immediately.

You may face this problem when logging on to Windows. When you type user name and password you are again presented with User name and Password dialogue box. You try hard to get in but to no avail.

You may not be able to log on to system using either Normal Mode or Safe Mode. This occur only when Winlogon service tries to load the Windows default shell (explorer.exe) and user shell (userinit.exe) from registry. This service searches for Explorer.exe and Userinit.exe in the following path of registry:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

Edit these values and type the correct path of shell :

            Shell = explorer.exe

            Userinit=X:\windows\system32\userinit.exe

NOTE: These files may also be deleted by spywares. You may need to extract them using Windows CD. 

Steps for rectifying this problem:

  • Log on to a networked computer.
  • Run Regedit.exe
  • Point your cursor to HKEY_LOCAL_MACHINE
  • Select File > Connect Remote Registry
  • Type computer name (infected computer)
  • Navigate to the following location in registry of destination or infected computer

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

  • Edit these two values in right pane:

                  Shell

                  Userinit

  • Change these two values to

                  Shell=explorer.exe

                  Userinit = x:\windows\system32\userinit.exe

  • Exit from Registry
  • Restart Infected computer.
  • You should be able to log on to computer.

LDIFDE – Export / Import data from Active Directory

LDIFDE is a robust utility. This utility enables you to import/export information from/to Active Directory. LDIFDE queries any available domain controller to retrieve/update AD information.

LDIFDE NOTE:

1. You can use LDIFDE to find any object. It may be a printer, a server, a computer, a user, a person. All these objects are identified with *ObjectClass=object_class_name (either printer or user or OU).

2. By default account is disabled when imported and also password is set to NULL.

3. To modify AD attribute you must put “-“ on a single line followed by a completely blank line on the next line. Please see the format below.

4. When a user is exported to LDF file, by default “changetype” is Add.

5. LDIFDE doesn’t support changing Group Membership. You can use CSVDE or ADDUSERS.exe or DStools for Windows 2003 Editions.

6. LDIFDE doesn’t support exporting Passwords.

7. By default “User must change password at next logon” attribute is selected.

8. LDIFDE doesn’t support importing Passwords. To change user’s password you need to convert from Plain Text to Base64 character. We can use a utility to convert from Plain Text to Base64.

9. Note that if no credentials are specified LDIFDE will use the currently logged on user’s credentials.

10. If you do an LDIFDE or CSVDE export, many of the attributes for user and group objects are owned by the system and cannot be re imported. Here’s a trick. Run the export with the –m switch. This enables SAM Logic, which is another way of saying that the export skips the attributes that are owned by the system. This gives you a template to use when building your import files or spreadsheets.

11. You can also export all user accounts from a forest (including data from all domains). This requires that you run the LDIFDE command against a Global Catalog Server with –t switch to specify the port No.

12. You must place a “-“ and then a blank line very next followed by the “-“ for modify and change operation to work properly. Otherwise LDIFDE will fail!

13. Using the setting “userAccountControl: 66048” enables the newly created account. By default, an account is created disabled. Note that user account can’t be enabled with blank password if you have a complex password policy defined on the domain. So you’re first step is to change the password and then enable the account.

                        userAccountControl: 514 for disable account

14. There are more export-specific options but not Import. Note that while exporting user accounts/OU/person you can use –o with –I but you can’t use both the switches while importing the file to AD. This is because both the switches are export-specific.

15. The default mode is Export Mode. You need to specify –I to turn Import Mode on.

16. If you want to carry the line to next line then the first must be a space and then start new line.

17. If you do not specify a server when you use LDIFDE to export objects that are in the domain-naming context, LDIFDE searches for a global catalog server. When LDIFDE searches for a global catalog server, it may not use the domain of the object name or the user account that you specify to determine what global catalog server to connect to. LDIFDE may connect to a global catalog server that is in the same site as the client, but that is a member of a different domain in the forest. This global catalog server may not have all the required Active Directory attributes for the objects that you want to export.  To work around this issue, use the -s server_name command-line option to specify a server when you use LDIFDE.

18. Ldifde sets password to blank unless you don’t have a complex password policy defined in your domain. Hence you can’t enable accounts with Blank Password.

19. Note that –o switch overrides –I switch if you plan to use both. Suppose you want to omit badPwdCount attribute from export and in the same command you specify –I switch to export this field. In this case attribute won’t be exported.

20. The contents of an object are on consecutive lines, starting with DN property. There must be an Empty Line if you want to perform an operation on another object.

21. Each property and its value must be on a separate line such as: givenname: dinesh. There should be a colon and a space.

22. DN property and its value must be placed at first line and any other property/value can be at any line.

23. Multiple values of a property should be on a separate line such as:

            Otherhomephoneno: 512 513

            Otherhomephoneno: 514 859

24. An empty value can be written by including only the property name with colon such as:    sn:

25. A line that starts with pound (#) sign is a comment line.

26. Base64 Encoding works as follow:

a. The value to be encoded is divided into three-byte sections

b. Each 24-bit Section is divided into four 6-bit value

               c. Each 6-bit value is mapped to one of the following 64 characters: uppercase alphabets A through Z, lowercase alphabets a through z, numbers 0 through 9, plus

               sign (+), or slash (/).This results in a string of basic alphabets, numbers, and possibly some plus signs and slashes. If the number of bytes in the original value is not a 

               multiple of three, the encoded value will have one or two equals signs (=) at the end, so the number of characters is always a multiple of four.

27. LDIFDE exports only attributes those have their values in AD. It doesn’t export attributes those don’t have values. For example: if description is not defined for a user then it won’t export description attribute.

28. When exporting ONLY ONE USER, make sure you don’t have dash (-) after the end of file.

29. When a new user account is created, it is made member of Domain Users group by default.

30. LDIFDE doesn’t accept blank values. Do not include blank values in LDF files. You will see errors.

31. LDIFDE doesn’t accept space in value while exporting. For example if samaccountname is Jacson Sam then you should enclose it within the quotas.

LDIFDE COMMANDS:

1. Command to export the user with a given name of SAM Account

ldifde -f exportuser.ldf -s computer_name -r (samaccountname=SAMLNAME)

2. Command to export Organizational Units:

Running this command exports all OUs except domain controllers into a file named ExportOU.ldf. 

ldifde -f exportOu.ldf -s Server1 -d “dc=Export,dc=com” -p subtree -r “(objectClass=organizationalUnit)” -l “cn,objectclass,ou”

3. Export the User Accounts from the Source Domain

ldifde -f Exportuser.ldf -s Server1 -d “dc=Export,dc=com” -p subtree -r “(&(objectCategory=person)(objectClass=User)(givenname=*))” -l “cn,givenName,objectclass,samAccountName”

Running this command exports all users in the Export domain into a file named Exportuser.ldf. If you do not have all the required attributes, the import operation does not work. The attributes objectclass and samAccountName are required, but more can be added as needed.

4. Command to Import users from a LDF file:

ldifde -i -f Exportuser.ldf -s Server2

5. Exporting User Account attributes except attributes those can’t be imported: (Using –o switch)

This is another example filter that will export all User Account data except for the attributes that cannot be imported:

ldifde -f Exportuser.ldf -s <Server1> -d “dc=Export,dc=com” -p subtree -r “(&(objectCategory=person)(objectClass=User)(givenname=*))” -o “badPasswordTime,badPwdCount,lastLogoff,lastLogon,logonCount, memberOf,objectGUID,objectSid,primaryGroupID,pwdLastSet,sAMAccountType”

Another Example: To export for any given SamAccountName:

ldifde -f Exportuser.ldf -s <Server1> -d “dc=Export,dc=com” -p subtree -r “(&(objectCategory=person)(objectClass=User)(givenname=*))” -o “badPasswordTime,badPwdCount,lastLogoff,lastLogon,logonCount, memberOf,objectGUID,objectSid,primaryGroupID,pwdLastSet,sAMAccountType”

6. Exporting Objects from an Entire Forest (any given attribute will be exported with –i switch)

If you need to import everything from a forest you need to run LDIFDE command against Global Catalog server:

For example, to perform the export operation outlined against a GC, the LDIFDE command would be:

ldifde -f Exportuser.ldf -s Server1 -t 3268 -d “dc=Export,dc=com” -p subtree -r “(&(objectCategory=person)(objectClass=User)(givenname=*))” -l “cn,givenName,objectclass,sAMAccountName”

7. Simple Import of current domain: It will import only domain data NOT the Forest-Specific.

ldifde -i -f INPUT.LDF

8. Simple Export of current domain:   It will export only domain related data NOT the Forest-Specific.

ldifde -f OUTPUT.LDF

9. Export of a domain with supplied credentials:

ldifde -m -f OUTPUT.LDF -b USERNAME DOMAINNAME -s SERVERNAME

           -d “cn=users,DC=DOMAINNAME,DC=Microsoft,DC=Com”

           -r “(objectClass=user)”

10. Exporting User or Person or Organizational Unit:

ldifde -v -s w2ks -d “dc=slowe,dc=com” -p subtree -r “(objectClass=clss_name)” -f usersonly.txt

You’ll notice a number of additional parameters here:

  • ·        -v turns on verbose mode so that I could see the results
  • ·        -d specifies the root of the search. While it was not required for this search, I included it to show you the format.
  • ·        -p narrows the search to the subtree in question. The other options for the –p parameter are base and onelevel.
  • ·        -r is used in the example with a parameter of “(objectClass=person)”. This parameter specifies the LDAP filter to use for LDIFDE. In my case, I wanted only people, so I chose an objectClass of “person.”

11. A Simple VBScript to change a user’s password: You can also modify strUser and strOU value:

strUser = InputBox(“Enter full name of user”)

strOU = InputBox(“Enter OU where user’s account resides”)

Set objUser = GetObject(“LDAP://CN=” & strUser & “,OU=” & strOU & “,DC=testdomain,DC=local”)

objUser.SetPassword “password”

MsgBox “Done!”

12. To change a user’s password using LDIFDE tool:

The following sample Ldif file (chPwd.ldif) changes a password to newPassword:

dn: CN=TestUser,DC=testdomain,DC=com
changetype: modify
replace: unicodePwd
unicodePwd::IgBuAGUAdwBQAGEAcwBzAHcAbwByAGQAIgA=

ldifde -i -f chPwd.ldif -t 636 -s dcname -b username domain password