Cách cấu hình Google Apps với Microsoft AD

Moving to Google Apps doesn’t mean having to recreate user accounts. Learn how you can leverage your existing Active Directory for easy setup.

Single Sign-on (the ability to use one account across multiple connected platforms) has been a holy grail for IT administrators for years now, and some have fared better than others in achieving this prize. I worked for a large bank in the late 1990’s which pursued a single sign-on project to link OS2/Novell Netware/mainframe accounts (no, we were not dodging pterodactyls at the time, though it does seem like an eon or two ago – this was back when a pager was considered high technology). Once rolled out, this was a clunky, kludgy affair which basically worked only if you held your breath, wore a purple shirt, and had a shaman casting the appropriate spells to ease the process.

Modern times

Fortunately, things have come a long way since then and LDAP (Lightweight Directory Access Protocol) has been a big factor in this evolution. It’s now common to configure systems to perform LDAP lookups against directory services to permit existing users to access new environments without needing a second account, nor to have to maintain different passwords (ahem, not that many users do willingly stop using one password for everything!)

In some cases these LDAP connections are used to actually synchronize separate accounts on different platforms so they are exactly alike, including the passwords. This can cloud the definition of “Single Sign-on” from an administrative perspective (since “multiple-but-identical” and not “single” accounts are used), but from the user’s point of view it meets the criteria so long as they can change passwords in one place.

Arguably, the most common and well-known directory service is Microsoft’s Active Directory. When considering a Google Apps migration you should know that you can use your current Active Directory with Google systems to import your user accounts so they will be generated in your Google Apps directory, eliminating any need to recreate these accounts if you opt to move to Google Apps. This isn’t a one-shot process, either: regularly scheduled synchronizations from Active Directory can keep these accounts updated in Google (for instance if properties such as a user’s mobile number change). This means you can keep Active Directory in-house and still rely on Google Apps. As a control freak, I find this immensely appealing.

Not using Active Directory? Google offers a similar option for other directory platforms such as Lotus Domino, open LDAP or several other solutions.

How does it work?

Google offers a free tool called Google Apps Directory Sync. This is a program which can be installed on any system in your internal network (Windows XP/7/2003/2008, Linux or Solaris. The tool synchronizes Google Apps users with Active Directory (or other directory) users, making them exactly alike, sort of like the Guy Fawkes impersonators at the end of the film “V for Vendetta“.

The process occurs as follows (Screenshots for this article provided by the Google Apps Directory Sync tutorial video.)

Figure A

The screenshot above shows the communication path between Google Apps and your LDAP server, which for Active Directory would be your domain controller.

It should go without saying that providing an outside server with direct access to your domain controller through the firewall would be an extremely bad idea from a security perspective (sort of like telling the plumber who’s fixing your sink to just pay himself from the uncounted pile of money in the safe).

Installing the Directory Sync tool on a separate machine alleviates this concern; it relies upon a trusted middleman, and LDAP data is NOT stored locally on this system. As an added bonus, the Directory Sync system very likely already has the necessary network access for this to work: the ability to perform LDAP lookups against the domain controller on port 389 and to connect to Google Apps via https on port 443, so you won’t need to deal with NAT setups, VPN tunnels or firewall changes.

The synchronization can be customized so that only the desired Active Directory objects (e.g. test users for a pilot rollout) are copied to Google – you can do this in a number of ways, such as by OUs, groups or custom attributes. Additionally, it is a one way process, copying objects from Active Directory to Google; any changes made to these objects needs to be performed in Active Directory.

While a two-way synchronization can seem desirable for convenience sake, the one-way option offers you protection in the event of problems with your objects. Keeping things balanced evenly across disparate environments can be tough. As someone who has lost data which was configured to synchronize between a hard drive and USB drive – and suffered havoc when the data on the USB drive got corrupted and THEN overwrote the good files on the hard drive – I can appreciate this safeguard.

What do I need to do?

The full guide outlines the step-by-step details; my goal here is to provide a high-level summary to go over the basics. For starters you must have administrator rights both in AD and your Google Apps environments. A setting in the Google Apps Control Panel called “Enable provisioning API” must be turned on. (Figure B)

Figure B

The Google Apps Directory Sync utility must be installed on a designated system in your environment. You will then need to run the Configuration Manager, which configures your synchronization options. (Figure C)

Figure C

You can set up the connection to Google Apps either directly using administrative credentials or via the more secure oAuth option which utilizes a security token, the LDAP configuration, and which objects to synchronize. Options include the ability to synchronize OUs, groups, users, user profiles, shared contacts and calendar resources.

You can map objects in AD to objects in Google Apps – the Finance OU to a new “Finance” Group for instance. You can also configure notifications so you’ll be aware of what worked/failed, as well as logging.

Best of all, you have the ability to run a “Simulated sync” to confirm everything will work properly via a test operation before you proceed; this will allow you to look for and correct any issues so you’re not forced to fix things on the fly.

Once you’re good with the setup and have run it successfully, the synchronization can be scheduled using the sync-cmd command line utility which can be scripted via the local task scheduler on the Directory Sync system.

There is also the option to use secure LDAP if you’re ultra-vigilant (although please keep in mind this would only apply to the internal Directory Sync system’s connection to your internal domain controller; the https connection to Google Apps is already encrypted – basically, it would be like hiring a police escort to walk your kids to the bathroom of your house). A word to the wise: having worked recently with secure LDAP via another venture, I have found it crucial to make sure the internal network infrastructure can support these connections and the appropriate ports are open.

So what about passwords?

Well, that’s the tricky part. Passwords do not synchronize in the default configuration (the native Active Directory and Lotus Domino password formats are not supported). The Google Apps Password Sync utility is needed if you want passwords to work across AD-Google Apps. This requires all password changes to be performed in Active Directory.

How do the imported objects look in Google Apps?

They look like any other standard objects and appear in the Contacts section (this applies to both users and shared contacts), as shown in Figure D.

Figure D

How can I get started?

The full admin guide is available from the “Google Apps Directory Sync” support page. This page also contains multimedia presentations outlining the steps involved. This is a very straightforward setup which will provide you with plenty of flexibility and ease of administration should you need to implement it.

Lưu ý về cách sử dụng mới: Windows PowerShell for Office 365

Use Windows PowerShell to manage Office 365

Windows PowerShell Command Builder

Use Windows PowerShell in Exchange Online

Install the Office 365 cmdlets

You can install the cmdlets on a Windows 7 or Windows Server 2008 R2 computer.

You must have Windows PowerShell and the .NET Framework 3.5.1 enabled.

You must install the Microsoft Online Services Sign-in Assistant. Download and install one of the following from the Microsoft Download Center:

To install the Microsoft Online Services Sign-in Assistant:

Microsoft Online Services Sign-In Assistant (IDCRL7) – 32 bit version http://go.microsoft.com/fwlink/p/?linkid=236299

Microsoft Online Services Sign-In Assistant (IDCRL7) – 64 bit version http://go.microsoft.com/fwlink/p/?linkid=236300

To install the Microsoft Online Services Module for Windows PowerShell:

Microsoft Online Services Module for Windows PowerShell (32-bit version) http://go.microsoft.com/fwlink/p/?linkid=236298

Microsoft Online Services Module for Windows PowerShell (64-bit version) http://go.microsoft.com/fwlink/p/?linkid=236297

For more information regarding this article, see the information within the link below:

Use Windows PowerShell to manage Office 365


Download and Install the Microsoft Online Services Module for Windows PowerShell for Single Sign on.


Click Start > All Programs > Microsoft Online Services (Folder) and select Microsoft Online Services Module for Windows PowerShell

hoặc Windows Azure Active Directory > Windows Azure Active Directory Module for Windows PowerShell


Method 1:

How to connect BOTH PowerShell (MOSMWP) and (PS) in one session using Microsoft Online Services Module for Windows PowerShell and Windows PowerShell to Exchange online (O365).

Copy and paste the commands below:

$LiveCred = Get-Credential
Connect-MSOLservice –Credential $livecred
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri
https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

Method 2:

How to Connect to Exchange online (O365) using the Microsoft Online Services Module for Windows PowerShell session (MOSMWP)

Import-Module MSOnline
$Creds = Get-Credential
Connect-MsolService –Credential $Creds

Method 3:

Connect-MsolService -Credential $cred

How to connect BOTH commands in one session using Regular Windows PowerShell PS (Blue):

Import-module msonline
$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri
https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

To connect to regular Windows PowerShell 2.0 run the command bellow:

$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri
https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

1. Additional troubleshooting information:

To Verify the version application, run the command below:


To Verify that WinRMto connect with O365, run the following commands together:

net start winrm
winrm get winrm/config/client/auth

To Configure WinRM to support basic authentication:
winrm set winrm/config/client/auth @{Basic=”true”}

If The customer was getting some sorts of restriction, the customer enter the following command “

To fix this issue use Run the command bellow:

Set-ExecutionPolicy RemoteSigned

Set-ExecutionPolicy Unrestricted

If the organization has a GPO that has restricted policy, run ther command below:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy unrestricted -force

Additional commands:

Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy unrestricted -force

Set-ExecutionPolicy -Scope MachinePolicy -ExecutionPolicy unrestricted -force

Set-ExecutionPolicy -Scope UserPolicy -ExecutionPolicy unrestricted -force

Set-ExecutionPolicy -Scope Process -ExecutionPolicy unrestricted -force

For more information click here

2. Assign the administrator in the “Organization Management”

If the administrator are having credential issues try the following steps:

In the Exchange Control Panel

1. Select Manage My Organization > Roles & Auditing > Administrator Roles.

2. Click “Organization Management” > details then Add the user as “Member” > Save

Administrator Role Groups in Exchange Online

  • 3. Administrators cannot authenticate to Office 365 by using the following management tools:
    • Microsoft Online Services Directory Synchronization tool (on the directory synchronization server)
    • Microsoft Online Services Module for Windows PowerShell (on a computer on which it is installed)
    • Network connectivity to Office 365 is limited.
    • The firewall, proxy servers, or both require local authentication.
    • Prerequisites of the rich client application are not met.
    • An old version of the Microsoft Online Services Sign-in Assistant is installed.
    • The rich client application is not configured for Office 365.

    Resolution 1: Network connectivity is limited

    Use a browser and try to visit http://www.msn.com

    . If you cannot access this website, troubleshoot network connectivity issues.

    1. At a command prompt, use the ipconfig and ping tools to troubleshoot IP connectivity. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:

      How to troubleshoot basic TCP/IP problems

    2. At a command prompt, run nslookup http://www.msn.com to determine whether DNS is resolving Internet server names.
    3. Make sure that the proxy server settings in Internet Options reflect the appropriate proxy server, if a proxy server is used in the local network.
    4. If a Forefront Threat Management Gateway (TMG) firewall is installed on the boundary of the network and the firewall requires client authentication, you might have to install and configure the Forefront TMG client program on the client device for Internet access. Contact your Office 365 administrator for help.

    Resolution 2: Firewall or proxy servers require additional authentication

    To resolve this issue, configure an exception for Microsoft Online Services URLs and applications from the authentication proxy. For example, if you are running Microsoft Internet Security and Acceleration Server (ISA) 2006, create an “allow” rule that meets the following criteria:

    • Allow outbound connections to the following destination: *.microsoftonline.com
    • Allow outbound connections to the following destination: *.microsoftonline-p.com
    • Allow outbound connections to the following destination: *.sharepoint.com
    • Allow outbound connections to the following destination: *.outlook.com
    • Allow outbound connections to the following destination: *.lync.com
    • Allow outbound connections to the following destination: osub.microsoft.com
    • Ports 80/443
    • Protocols TCP and HTTPS
    • Rule must apply to all users.
    • HTTPS/SSL time-out set to 8 hours

    Cấu hình ADFS 2.0 dùng cho Single Sign On for Office 365

    in Office 365. This article takes you through the steps of achieving it.

    First, do remember the following points if you are going ahead with Single Sign-On in Office 365.

    • You need to have ADFS 2.0 on one server & Directory Synchronization (Dirsync) on another server in your on premise environment.
    • You need to make sure that ADFS server is ALWAYS up and running. If it crashes, because of any reason, federated users will not be able to Login to Office 365.

    Keeping the above points in mind, let me start of by taking an example of a typical SMB environment

    Environment Details (each on different server)

    • Domain Controller
    • ADFS 2.0
    • DirSync
    • Exchange 2007 (or 2010)
    • SharePoint 2007 (or 2010)

    Step 1 : Add Host record in your public DNS ( such as godaddy.com) for your ADFS 2.0 Server.

    Step 2: Install ADFS 2.0 (Find the snapshots below)

    • Download ADFS 2.0 on the ADFS Server
    • Install IIS on ADFS Server
    • Get a Enterprise CA Certificate and bind it to Default web site,port 443, in IIS on ADFS 2.0 server.

    NOTE : Register and verification of the domain in Office 365 has to be done before you configure ADFS (not covered in this article)

    Snapshots for ADFS installation and configuration


    Leave the check mark as it is and this will start the configuration wizard automatically.

    Click on ADFS 2.0 Federation Server Configuration Wizard.

    Choose New Federation Service as its the first ADFS 2.0 Server in the farm.

    New Federation Server Farm : this is used when you have plans of having more than one ADFS server in your environment. With Office 365, I recommend this option as I mentioned earlier in the post if ADFS 2.0 goes down, none of your federated users will be able to login to Office 365. So have more than one ADFS server & providing High Availability using Load balancing is recommended.

    Stand-alone federation Server : Used in testing environment or small production environment. Cannot add more than servers to make it a server farm.

    Click Next after choosing the appropriate option.

    Verify if this stage shows the right certificate , port and federation service name.

    On the Summary screen click next and then click finish.

    ADFS is now installed and configured.

    Step 3: Download Microsoft Online Services Module for Windows PowerShell

    • To download this tool, login to http://portal.microsoftonline.com, Click On Users under Management.
    • At the right top of the screen, you will see “Single sign-on: Manage | Learn more” ,click on Manage
    • Third step will say “Install the Microsoft Online Services Module for Windows PowerShell
    • Download and install it. Installation is very simple.

    Step 4: After the tool is installed, run the “Office Desktop Apps” wizard

    Click on “Set Up” -> Select the application and then click “I accept”.

    The wizard will configure your Rich Clients to work with Office 365. Once the installation is complete you will see the below screen

    Almost done!!…

    Only thing left is to make the domain federated. To make a domain as federated domain, you will have to first register and verify the domain. (Register and verification of domain in Office 365 has to be done before you configure ADFS)

    Assuming that you have done the domain verification, double click on the shortcut of Microsoft Online Services Identity Federation Management Tool in desktop.

    Run the following commands

      • $cred = Get-Credential
    You will get a prompt to enter credentials. Enter the Admin account of Office 365 (tenant admin account)
      • Set-MSOLContextCredential -MSOLAdminCredentials $cred
    • Add-MSOLFederatedDomain -DomainName <DOMAIN NAME>

      < DOMAIN NAME> = enter your verified domain name which you want to federate.

    To verify that your domain is configured successfully, do the following:

    1. Log on to http://portal.microsoftonline.com using your admin credentials.
    2. Click on Domain under Management
    3. Click on the domain that you just federated
    4. Under the Domain Properties, you should see “Domain Type: Single sign-on: This domain is configured for single sign-on

    Get the users on cloud using DirSync and start using Office 365 services VIA single sign-on.

    Làm thế nào để thay đổi Work email trong Personal Settings–SharePoint 2010

    Câu hỏi:

    I need to change a user’s email in User Information in a site. Typically the user has an AD account, but their own email address in the case of contractors. When I add a user to the site, the email in AD comes through, but I don’t want that email, I want their email and when I click on the Edit Item link, the Edit Personal Settings dialog box does not have a control to edit their email address. How do I turn this on so I can edit their email address?

    I’ve already gone into Service Applications in Central Administration and in the User Profile Service Application went into Manage User Properties and configured Work Email to be editable by users, and I have already checked the job to see that it has run, but I am still unable to edit an email address in a user’s account.

    How do I do this please?

    Thank you.


    Câu trả lời:

    A user’s Email Address is stored within a profile property. By default a user isn’t allowed to change his or her own e-mail address. The email address (Work e-mail) and whether or not user’s can change their own can be specified in the settings of the User Profile Service Application.

    1. (As an administrator) open Central Admin
    2. Under “Application Management” click “Manage Service Applications”
    3. Locate and click the link “User Profile Service Application”. If this one is not there you haven’t created a User Profile Service Application yet.
    4. Under “People” there are two relevant links here. The first is “Manage User Properties”, the second is “Manage User Profiles”
    5. Under “Manage User Properties” you can specify the settings for the Work e-mail property (i.e. whether or not the user is allowed to edit his or her own e-mail address).
    6. Under “Manage User Profiles” you can locate a user’s profile and edit the e-mail address from there.

    By default it could take up to one hour to “see” the new e-mail address throughout all web applications bound to the user profile service application. A timer job is taking care of this and you could kick this one of to run manually once by going to “Check Job Status” screen in Central Admin (_admin/Timer.aspx). Here locate the job definition with the title “User Profile Service Application – User Profile to SharePoint Full Synchronization”, open the “Edit Timer Job Page” by clicking on the Job’s name and then click the “Run Now” button.

    Làm thế nào để đồng bộ Active Directory Sync trong khi Username và Password bị mã hoá theo OS 32/64bit ? (tiếp theo)

    Phần 1: tìm hiểu về các cơ chế lưu hash password trên OS

    Windows Security Account Manager
    Slightly modified definition from Wikipedia:

    The Security Accounts Manager (SAM) is a registry file in Windows NT and later versions until the most recent Windows 7. It stores users’ passwords in a hashed format (in LM hash and NTLM hash). Since a hash function is one-way, this provides some measure of security for the storage of the passwords.

    Generally, dumping operating system users’ password hashes is a common action following a compromise of a machine: getting access to the password hashes might open the doors to a variety of attacks including, but not limited to, authenticate with the hash over SMB to other systems where passwords are reused, password policy analysis and pattern recognition, password cracking, etc.

    Depending on the type of access that you have got to the target, you can retrieve the password hashes from SAM in different ways.

    Physical access

    Given physical access to the system, typically during a laptop assessment or a successful social engineering engagement, the preferred way to safely dump the password hashes is to power off the machine, enter the BIOS menu at power-on time, review the boot order to allow boot from the optical drive and USB drive before local hard-disk, save the settings and reboot the system with your favourite GNU/Linux live distribution CD or USB stick. Two widely known tools to dump the local users’ hashes from the SAM file, given the Windows file system block file, are bkhive and samdump2:

    • bkhive – dumps the syskey bootkey from a Windows system hive.
    • samdump2 – dumps Windows 2k/NT/XP/Vista password hashes.

    These tools are generally included in many GNU/Linux live distributions. If they’re not, make sure to bring a copy of them with you.


    # bkhive
    bkhive 1.1.1 by Objectif Securite
    original author: ncuomo@studenti.unina.it

    bkhive systemhive keyfile

    # samdump2
    samdump2 1.1.1 by Objectif Securite
    original author: ncuomo@studenti.unina.it

    samdump2 samhive keyfile

    Example of retrieving the SAM hashes from a Windows partition /dev/sda1:

    # mkdir -p /mnt/sda1
    # mount /dev/sda1 /mnt/sda1
    # bkhive /mnt/sda1/Windows/System32/config/SYSTEM /tmp/saved-syskey.txt
    # samdump2 /mnt/sda1/Windows/System32/config/SAM /tmp/saved-syskey.txt > /tmp/hashes.txt

    In the event that you have not got bkhive or samdump2 with you, you can fall-back to copy the SYSTEM and SAM files from /mnt/sda1/Windows/System32/config to your USB stick and import them to any tool that is able to extract the SAM hashes from them: Cain & Abel, creddump and mimikatz are some available tools.

    Bypass login prompt

    If you are looking into bypassing the login prompt rather than dumping users’ password hashes, some smart people have came up with innovative approaches:

    • BootRoot is a project presented at Black Hat USA 2005 by researchers Derek Soeder and Ryan Permeh, as an exploration of technology that custom boot sector code can use to subvert the Windows kernel as it loads. The eEye BootRootKit is a boot sector-based NDIS backdoor that demonstrates the implementation of this technology.
    • SysRQ2 is a bootable CD image that allows a user to open a fully privileged (SYSTEM) command prompt on Windows 2000, Windows XP, and Windows Server 2003 systems by pressing Ctrl+Shift+SysRq at any time after startup. It was first demonstrated at Black Hat USA 2005 by researchers Derek Soeder and Ryan Permeh as an example of applied eEye BootRoot technology. Use the “create CD from ISO image” feature of your preferred CD burning software to create a bootable SysRq CD.
    • Kon-Boot is an prototype piece of software which allows to change contents of a linux kernel and Windows kernel on the fly (while booting). In the current compilation state it allows to log into a linux system as root user without typing the correct password or to elevate privileges from current user to root. For Windows systems it allows to enter any password protected profile without any knowledge of the password.

    Password reset

    Alternatively you can boot the machine with the bootdisk live CD or USB stick and use the chntpw utility to reset any Windows local user’s credentials.

    Post-exploitation scenario

    The typical scenario here is that you have compromised a Windows machine by any means and have got shell access as an administrative user. Firstly, you need to escalate your privileges to SYSTEM user. A simple way is to use Sysinternals’ PsExec utility:

    C:\>psexec.exe -i -s cmd.exe

    Although, there are several other techniques too, but this is outside of the scope of this post.

    Legacy techniques

    On Windows NT and Windows 2000 systems you can use Ntbackup utility part of the MS-DOS subsystem: Backup the system state into a file locally on the machine you have compromised, then using Ntbackup again, restore the system state stuff to a local directory without preserving the security. Once complete, you will have the SAM and SYSTEM files. You need about 280Mb for the initial backup – typical for a Windows 2000 with current service packs and hot fixes.
    On modern releases of Windows, you can use Wbadmin, an alternative to Ntbackup.

    Another solution is to use regback.exe part of the Windows 2000 Resource Kit Tools. This is slightly easier as it only dumps the specific files:

    C:\>regback.exe C:\backtemp\SAM machine sam
    C:\>regback.exe C:\backtemp\SYSTEM machine system

    If you cannot get regback.exe to work, on Windows XP and above systems use regedit.exe or reg.exe. Using reg.exe:

    C:\>reg.exe save HKLM\SAM sam
    The operation completed successfully
    C:\>reg.exe save HKLM\SYSTEM sys
    The operation completed successfully

    Using regedit.exe:

    • Execute regedit.exe from Start / Run prompt.
    • Open up Computer\HKEY_LOCAL_MACHINE and right-click the SAM section and select Export.
    • Change the Save as type setting to Registry Hive Files and save as SAM.
    • Same steps with SYSTEM hive.

    Lastly, you can also get the SAM and SYSTEM files from C:\Windows\repair\. Although this directory contains outdated copies of the original C:\Windows\System32\config\ files so it might not reflect the current users’ credentials.

    Volume Shadow Copies technique

    This technique is fairly recent and was first illustrated by Tim Tomes. It consists of abusing the Volume Shadow Copies functionality in modern Windows operating systems to access locked system files like C:\Windows\System32\config’s SAM and SYSTEM and others.

    You can use the Volume Shadow Copy Management command line interface, vssown, to leverage this technique as follows.

    List shadow copies:

    C:\>cscript vssown.vbs /list
    Microsoft (R) Windows Script Host Version 5.8
    Copyright (C) Microsoft Corporation. All rights reserved.


    As expected, no shadow copies initially.

    Verify the status of the Volume Shadow Service (VSS):

    C:\>cscript vssown.vbs /status
    Microsoft (R) Windows Script Host Version 5.8
    Copyright (C) Microsoft Corporation. All rights reserved.

    [*] Stopped

    C:\>cscript vssown.vbs /mode
    Microsoft (R) Windows Script Host Version 5.8
    Copyright (C) Microsoft Corporation. All rights reserved.

    [*] VSS service set to ‘Manual’ start mode.

    In this case, once we are done, we need to restore it to the initial state (Stopped).

    Create a new shadow copy:

    C:\>cscript vssown.vbs /create
    Microsoft (R) Windows Script Host Version 5.8
    Copyright (C) Microsoft Corporation. All rights reserved.

    [*] Attempting to create a shadow copy.

    Verify that the shadow copy has been created:

    C:\>cscript vssown.vbs /list
    Microsoft (R) Windows Script Host Version 5.8
    Copyright (C) Microsoft Corporation. All rights reserved.


    [*] ID: {D79A4E73-CCAB-4151-B726-55F6C5C3A853}
    [*] Client accessible: True
    [*] Count: 1
    [*] Device object: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
    [*] Differnetial: True
    [*] Exposed locally: False
    [*] Exposed name:
    [*] Exposed remotely: False
    [*] Hardware assisted: False
    [*] Imported: False
    [*] No auto release: True
    [*] Not surfaced: False
    [*] No writers: True
    [*] Originating machine: LAPTOP
    [*] Persistent: True
    [*] Plex: False
    [*] Provider ID: {B5946137-7B9F-4925-AF80-51ABD60B20D5}
    [*] Service machine: LAPTOP
    [*] Set ID: {018D7854-5A28-42AE-8B10-99138C37112F}
    [*] State: 12
    [*] Transportable: False
    [*] Volume name: \\?\Volume{46f5ef63-8cca-11e0-88ac-806e6f6e6963}\

    You need to take note of the Device object value for the next step and the ID for the cleanup step.

    Pull the following files from a shadow copy:

    C:\>copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM .C:\>copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SAM .

    You have just copied over SAM and SYSTEM files from the shadow copy to the C:\ root folder.


    C:\>cscript vssown.vbs /delete {D79A4E73-CCAB-4151-B726-55F6C5C3A853}

    Microsoft (R) Windows Script Host Version 5.8
    Copyright (C) Microsoft Corporation. All rights reserved.

    [*] Attempting to delete shadow copy with ID: {D79A4E73-CCAB-4151-B726-55F6C5C3A853}

    Eventually, restore to original Stop status:

    C:\>cscript vssown.vbs /stop

    Microsoft (R) Windows Script Host Version 5.8
    Copyright (C) Microsoft Corporation. All rights reserved.

    [*] Signal sent to stop the VSS service.

    In-memory technique

    The concept behind in-memory dump of SAM hashes it to inject a DLL into the LSASS system process or, generally speaking, parsing the memory for specific patterns and inspect these memory pages’ content. The former action can lead to a Blue Screen of Death (BSoD) condition following a crash of the LSASS process therefore this action is not recommended on production environments: prefer registry hive copy (regback.exe and reg.exe/regedit.exe) and Volume Shadow Copies techniques instead. Nevertheless, in some specific instances, the in-memory technique is required.

    The most widely known standalone tool to dump SAM hashes is probably fgdump, the successor of pwdump6, both tools developed by the foofus team. The main advantage of fgdump over pwdump6 is that it works on Windows Vista and later versions. Although, I have seen them both failing under some circumstances. More reliable tools include pwdump7 from Andres Tarasco and the gsecdump from TrueSec. Both work on 32-bit and 64-bit systems across all versions of Windows. Although, the former cannot successfully dump users’ password hashes on domain controllers as it reads the SAM hashes from the registry rather than injecting into LSASS process. Despite not working on 64-bit systems, another popular and reliable tool is PWDumpX by Reed Arvin.

    The following screen-shot shows the dump of SAM users with gsecdump on a Windows Server 2003 SP2 32-bit:

    Dump of local users with gsecdump by code injection into the LSASS process

    The Metasploit Framework also has its own post-exploitation modules, Meterpreter built-in command and dated Meterpreter script to dump the SAM hashes. Details on how these pieces of code work within the framework and which techniques they implement can be found on these blog posts by HD Moore.

    Needless to say that there are more options and knowledge of which one to use within the target environment is important. In order to facilitate this task, I have listed the relevant tools, their capabilities, where they do work and, most importantly, where they are known to fail on this spread-sheet.


    Phần 2: Tổng kết vấn đề lưu hash password

    Conclusions on Windows Security Account Manager
    In the previous post of this series, I briefly explained what the Windows Security Account Manager (SAM) is, how to dump Windows local users’ password hashes from SAM having physical access to the target system or following a remote compromise of the machine, post-exploitation.
    Remotely, there exist three possible techniques: legacy, volume shadow copies and in-memory dump. Lastly, I highlighted the most widely used tools for the in-memory hashes dump and I collected and released them in this spread-sheet along with other tools that I will discuss later.
    I want to reiterate the following concept: given file transfer ability between your machine and the target system, always prefer to copy the SAM and SECURITY files over from the target and extract the password hashes offline afterwards.
    Although, this safe approach to password hashes dump does not guarantee that you are going to obtain all Windows local accounts’ hashes. If you suspect that this is case, you will have to dump the hashes via in-memory dump and merge the results. Odd, but I have seen this happening quite a few times already and I am still discussing standalone Windows workstations, not part of a Windows domain.
    Preferred tools
    Personally, my first choice for standalone SAM hashes dump is pwdump7: it works on all Windows version from 2000 on both 32-bit and 64-bit systems. However, this tool does not perform an in-memory dump and could miss out hashes. I always run gsecdump along with pwdump7 to cover both techniques across all Windows versions and architecture and carefully launched once at a time do crash the LSASS process.
    When I have got a Metasploit Meterpreter shell onto the system, I rely on the post-exploitation module smart_hashdump by Carlos Perez, falling back to its predecessor post-exploitation module hashdump when it fails.
    Active Directory
    Definition from Wikipedia:

    Active Directory serves as a central location for network administration and security. It is responsible for authenticating and authorizing all users and computers within a network of Windows domain type, assigning and enforcing security policies for all computers in a network […] when a user logs into a computer that is part of a Windows domain, it is Active Directory that verifies his or her password […]

    This definition comes into play when you have compromised a system part of a Windows domain. In order to quickly extend your control over the whole domain, the goal is to compromise the root domain controller. If you are within a child domain, the final goal is to achieve Enterprise Domain Administrator level access onto the root domain controller of the Windows forest’s parent domain. There are plenty of resources on the Internet discussing domain escalation and this is out of the scope of this post series. A blog post that summarizes the best techniques and goes straight to the point is written by pentestmonkey.net. Alternatively, you can pass the local users’ hashes obtained from your entry point machines to keimpx and spray them against the domain controllers: if the system administrator reuses the same local Administrator password across all machines, you are in!
    Regardless of how you have compromised a domain controller, preferably the root domain controller as it is the first to get updated with changes to user accounts, the important is that you have got an administrator (local or domain) shell onto it.
    Database file NTDS.DIT
    The goal now is to dump the domain users’ password hashes. These are stored, along with nearly all the information that is accessible in the Active Directory (user objects, groups, membership information, etc), in a binary file, %SystemRoot%\ntds\NTDS.DIT.
    This file is locked by the system. You can use the volume shadow copies technique illustrated in the previous post to copy it along with the SYSTEM file over to your machine.
    Alternatively, use the ntdsutil snapshot facility introduced in Windows Server 2008. It will create a snapshot of the active directory database allowing you to copy ntds.dit and SYSTEM file. This technique is detailed on a Microsoft TechNet article.
    Extract hashes from NTDS.DIT
    You can use the passcape’s Windows Password Recovery tool to extract hashes from ntds.dit.
    Alternatively, you can use a couple of tools (ntds_dump_hash.zip) developed by Csaba Barta and documented in his paper titled Research paper about offline hash dump and forensic analysis of ntds.dit. These tools are used to:

    • Extract the required data from ntds.dit: esedbdumphash.
    • Decrypt the hashes and interpreting other information regarding the user account: dsdump.py, dsdumphistory.py, dsuserinfo.py.

    Download and compile the tool:

    $ wget http://csababarta.com/downloads/ntds_dump_hash.zip
    $ unzip ntds_dump_hash.zip
    $ cd libesedb
    $ ./configure && make

    Use esedbdumphash to extract the datatable from ntds.dit:

    $ cd esedbtools
    $ ./esedbdumphash -v -t /tmp/output <ntds.dit file>
    $ ls -1 /tmp/output.export/

    Use dsdump.py to dump the hashes from the datatable file using the bootkey (SYSKEY) from the SYSTEM hive:

    $ cd ../../creddump/
    $ chmod +x *.py
    $ ./dsuserinfo.py /tmp/output.export/datatable
    $ ./dsdump.py <SYSTEM file> /tmp/output.export/datatable –include-locked –include-disabled > domain_hashes.txt

    Like standalone machines, you can use the in-memory technique too to dump the domain users’ hashes. The tools are the same and work equally. Just be cautious when injecting into the LSASS process of a domain controller: in the worst case scenario, you will have to reboot an infrastructure-critical server.
    I have added these tools and improved the spread-sheet.
    Updates on January 4, 2012
    During December 2011, Csaba Barta has dug some more into NTDS.dit structure and as a result he has developed a new framework called NTDSXtract to extract information from database tables extracted with libesedb from ntds.dit file: both tools now support 64-bit derived database files too.

    Download and install the latest release of libesedb.

    Extract the database tables from ntds.dit:

    $ esedbexport -l /tmp/esedbexport.log -t /tmp/ntds.dit <ntds.dit file>
    esedbexport 20111210

    Opening file.
    Exporting table 1 (MSysObjects) out of 12.
    Exporting table 2 (MSysObjectsShadow) out of 12.
    Exporting table 3 (MSysUnicodeFixupVer2) out of 12.
    Exporting table 4 (datatable) out of 12.
    Exporting table 5 (hiddentable) out of 12.
    Exporting table 6 (link_table) out of 12.
    Exporting table 7 (sdpropcounttable) out of 12.
    Exporting table 8 (sdproptable) out of 12.
    Exporting table 9 (sd_table) out of 12.
    Exporting table 10 (MSysDefrag2) out of 12.
    Exporting table 11 (quota_table) out of 12.
    Exporting table 12 (quota_rebuild_progress_table) out of 12.
    Export completed.

    $ ls -1 /tmp/ntds.dit.export/

    Use NTDSXtract to parse the datatable and extract users’ information, including password hashes and history:

    ~/NTDSXtract 1.0$ python dsusers.py /tmp/ntds.dit.export/datatable.3 /tmp/ntds.dit.export/link_table.5 –passwordhashes <SYSTEM file> –passwordhistory <SYSTEM file> –certificates –supplcreds <SYSTEM file> –membership > /tmp/ntds.dit.output

    Use this small script that I have put together to process the output of NTDSXtract‘s dsusers.py into a “pwdump-alike” penetration tester’s friendly format:

    $ python ntdstopwdump.py /tmp/ntds.dit.output
    Administrator:500:NO PASSWORD*********************:09b1708f0ea4832b6d87b0ce07d7764b:::
    Guest:501:NO PASSWORD*********************:NO PASSWORD*********************:::

    Phần 3: lưu và rò vết Mật khẩu

    Password history
    In the previous two posts of this series, I discussed how to dump Windows local users’ password hashes (SAM) and Windows domain users’ password hashes from domain controllers (ntds.dit).
    When the password policy setting is configured to enforce password history, Windows stores a certain number of used passwords before an old password can be reused. The following screenshot shows you where this policy can be set.

    Local Security Policy (secpol.msc) / Account Policies / Password Policy / Enforce password history

    By default on workstations, this value is set to 0 and on domain controllers it is set to 24. This means that when dumping domain users’ hashes from active directory’s ntds.dit file, there are high chances to dump also the password history allowing you, during the password cracking phase, to recognise patterns used by the target users.
    Despite not being current password hashes, pattern identification can lead to further attacks. For instance, ease of guessing passwords used against standalone services at later stages of your post-exploitation. Therefore, never underestimate the added value provided by dumping and cracking the password history.
    Many of the tools introduced so far can dump the password history: Cain & Abel, PWDumpX along others. pwhist from Toolcrypt is also a valid option.
    LSA secrets
    LSA secrets is an area in the registry where Windows stores important information. This includes:

    • Account passwords for services that are set to run by operating system users as opposed to Local System, Network Service and Local Service.
    • Password used to logon to Windows if auto-logon is enabled or, generally, the password of the user logged to the console (DefaultPassword entry).

    LSA secrets are stored in registry hive HKEY_LOCAL_MACHINE/Security/Policy/Secrets. Each secret has its own key. The parent key, HKEY_LOCAL_MACHINE/Security/Policy, contains the data necessary for accessing and decoding the secrets.
    Dump LSA secrets
    As per SAM hashes, the LSA secrets can be accessed by DLL injection into the lsass.exe process or from the registry files.
    If you are Administrator and the target system is used in production, I recommend you to choose the safe path and copy off the system the registry files: SYSTEM and SECURITY: you can use the legacy registry hive copy (reg.exe/regedit.exe) or the volume shadow copies technique illustrated in the first post. Cain & Abel can extract LSA secrets from these files.
    Alternatively, there are numerous tools that can be used to dump LSA secrets by injecting into lsass.exe process: gsecdump has proved to be the most reliable for LSA secrets, working across all Windows versions and architectures. On 32-bit architecture, the original lsadump2 has proved to be good too. Despite my expectations, the two NirSoft tools (LSASecretsDump and LSASecretsView) have failed to dump services’ account passwords, regardless of the architecture.
    Regardless of the technique used, the passwords extracted are UTF-16 encoded. This means that they are in clear-text as opposed to SAM hashes. You can read a detailed description of the LSA secrets format here by Brendan Dolan-Gavitt.
    The following screen-shot shows the output of gsecdump on a Windows Server 2003 machine running IBM DB2 and PostgreSQL. Both database management systems run as Windows local users:

    Output of gsecdump.exe -l to dump LSA secrets

    Threats posed by LSA secrets

    Now, imagine that you have compromised a server part of a Windows domain, you have got a shell as Local System. If you want to extend your control over the network perimeter, one of the viable ways is to verify if any service runs as real operating system users and, if so, extract their clear-text password from LSA secrets.
    You can run services.msc from Start / Run and sort the entries by Log On As column to check this quickly. The following screen-shot demonstrates this:

    Services running as local users on Windows

    Obviously, the built-in sc.exe command can do the same as well as other less known tools.
    It is common to identify enterprise software like Veritas Netbackup, Microsoft SQL Server, Microsoft Exchange and others running as real users. More dangerously, sometimes system administrators opt to run services as domain users, if not domain administrators.
    This is clearly wrong and poses a high threat to overall security of the target Windows domain because, as an attacker, you can dump the LSA secrets and use the clear-text domain administrator password to login to the root domain controller and takeover the Windows network.

    Cached domain logon information
    Windows machines can be standalone workstations or part of a Windows domain in the role server or workstation.
    When a user logs onto a workstation part of a domain, technically he can either log as a local user or a domain user given that he has the credentials.
    When logging as a domain user, three information are required: username, password and domain name. The latter is usually provided as a drop-down menu listing all domains that the system is part of.
    Given this information, when the domain user logs onto the system, the provided password is hashed and checked over the network against the domain controller’s valid password hash (physically stored within ntds.dit file). This process is handled once again by the lsass.exe process.
    LSASS first checks if the domain controller is available. If so, it proceeds with the password hash matching step and, depending on the result, it allows or denies access to the system to the authenticating domain user.
    In the event that none of the domain controllers are available, the legitimate domain user would not be able to login onto the system. To avoid this from happening, Microsoft has long ago introduced the cached domain logon information mechanism in Windows.
    Definition from Microsoft:

    All previous users’ logon information is cached locally so that, in the event that a domain controller is unavailable during subsequent logon attempts, they are able to log on […]

    Therefore, when the domain controllers are not available, the domain user can still log onto the domain machine. The only caveats being that he has previously successfully logged and that the system is configured to cache the domain logon information. The following screenshot shows you where this policy is set.

    Local Security Policy (secpol.msc) / Local Policies / Security Options / Interactive logon: Number of previous logons to cache (in case domain controller is not available)

    You can also read the value of this policy in registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\CachedLogonsCount.
    By default Windows XP and above are configured to cache 10 or more domain logon information.
    Cached domain logon information is stored in registry hives HKEY_LOCAL_MACHINE/Security/CACHE/NL$X with X being a number. These registry hives are accessible by Local System and tools exist to dump them.
    Dump cached domain logon information
    Like other hashes, these hashes can be accessed by DLL injection into the lsass.exe process or from the registry files.
    For offline dump, copy off the system the registry files SYSTEM and SECURITY: you can use the legacy registry hive copy (reg.exe/regedit.exe) or the volume shadow copies technique illustrated in the first post. Cain & Abel, creddump by Brendan Dolan-Gavitt and Windows Password Recovery by passcape can extract cached domain logon information from these files.
    Alternatively, there are numerous tools that can dump this by DLL injection into lsass.exe process. On 32-bit architecture you can use the original cachedump by Arnaud Pilon which proved to be reliable also on recent Windows versions, fgdump or PWDumpX.
    Unfortunately though, none of the standalone free tools work on 64-bit architecture. In this case, you can rely on Metasploit Framework own post-exploitation module if you have got a Meterpreter shell onto the target system.
    Follows the output of cachedump on a Windows system part of a domain:

    C:\>cachedump.exe -v
    Service not found. Installing CacheDump Service (C:\cachedump.exe -s)
    CacheDump service successfully installed.
    Service started.
    Service currently active. Stopping service…
    Service successfully removed.

    Threats posed by cached domain logon information
    Similar scenario to LSA secrets dump: you have compromised a machine part of a Windows domain and have got a shell as Local System. There are no traces of domain users’ credentials from LSA secrets. Another step to extend your control over the domain? Check if the machine is configured to cache domain logon information as explained above. If so, dump them.
    Cached domain logon information cannot be directly used to authenticate to other systems as opposed to NT and LM password hashes. Nevertheless, you can crack them and use the clear-text password to authenticate to machines part of the relevant domain. I will cover password hashes cracking in depth in another blog post.
    Conceptually, caching domain logon information is effective and solves network administrators’ headaches to deal with domain users logons when the domain controllers are under maintenance or unavailable for whatever reason. Although, looking at it with the security lens, it clearly poses a security threat.


    Phần 5: Phiên đăng nhập

    Logon sessions
    Windows stores in memory information about every current and past successful logon. These are called logon session. This information includes the username, the domain or workgroup name and both the LM and NT password hashes.
    Every time a legitimate user logs onto a Windows system, the Local Security Authority (LSA) stores in memory this information. This happens regardless of the logon type: interactive logon to the console or remote logon via Remote Desktop Protocol (RDP).
    The image below from Hernan Ochoa illustrates this concept:

    Windows NT logon and authentication model

    The same information is stored for RunAs processes and services running as specific users. In the latter case, the clear-text password is stored in memory and can be retrieved in LSA secrets anyway.
    Exception being network logons, for instance over SMB or HTTP; these do not get stored because the NT/LM hashes never actually reach the server. A challenge-response mechanism is used for authentication.
    This sensible information is kept in memory because it is used for Single Sign-On (SSO) purposes.
    SSO technology is extensively used in Windows network, particularly within domains. This allows, for instance, a user logged into a certain system of the domain to access remote shares, shared resources like printers and HTTP proxy protected by NTLM authentication without the need to type in his clear-text credentials each time: Windows deals with the authentication for him transparently over the network by providing exactly what is stored in memory: username, domain/workgroup and password hashes.
    This authentication mechanism works because nowadays nearly all Windows services accept authentication with NT/LM hashes as an alternative to clear-text password. Exception being Remote Desktop Protocol.
    Dump logon sessions
    Logon sessions can be dumped given you have an administrative shell onto the target. There exist two techniques to dump logon sessions: code injection into lsass.exe process and reading of LSASS memory.
    There are several tools that can dump logon sessions: msvctl from TrueSec is a safe choices for Windows XP/2003 and is limited to 32-bit architecture. The updated version of gsecdump can dump logon sessions regardless of Windows version and architecture too. More recent tools include another nice piece of code from TrueSec, lslsass: this tool has been designed specifically for Windows Vista onwards and delivers reliable results regardless of the architecture.
    The most well known tools to manipulate Windows logon sessions are Windows Credentials Editor (WCE) and its predecessor, Pass-The-Hash Toolkit (PTK). Both are the result of thriving research by Hernan Ochoa, currently the founder of Amplia Security. His presentations include:

    • Pass-The-Hash Toolkit for Windows: Implementation & use presented at Hack In The Box Security Conference in Malaysia on late 2008. Despite being a dated presentation, it offers insight on the history and techniques used in post-exploitation scenarios, specifically focusing on the more generic Pass-the-Hash technique and its implementation in the Pass-The-Hash Toolkit.
    • WCE Internals presented at RootedCon in Madrid on early 2011. This presentation explains the inner workings of WCE including how Windows store credentials in memory pre and post Windows Vista.
    • Post-Exploitation with WCE presented on July 2011. Simple and effective high-level presentation with test cases. I recommend you reading this presentation before anything else if you are totally unfamiliar with logon sessions and pass-the-hash technique. Another good read is the tool’s FAQ page.

    Between these two tools, I prefer WCE for a number of reasons: it is one single executable, it is safer than all the other tools as it is the only one to implement the reading of LSASS memory technique as an alternative to performing code injection and it works across all Windows versions and on both architectures.

    For the purpose of this post, I have set a Windows Server 2003 R2 Service Pack 2 fully patched machine (NetBIOS name: w2k3r2) in the following state:

    • Local Administrator with a 15-characters long password logged interactively to the console.
    • Two local users, inquis and foobar, both connected over RDP, respectively using mstsc, the default RDP client on Windows, and rdesktop, a RDP client for Unix/Linux.
    • A few services, all related to IBM DB2 database management system, running as local administrator, db2admin.

    lslsass was deliberately excluded from my tests as it only works on Windows Vista onwards.

    All the tested tools were able dump the logon sessions successfully. Follows the output of Windows Credentials Editor:

    C:\>wce.exe -l

    WCE v1.2 (Windows Credentials Editor) – (c) 2010,2011 Amplia Security – by Hernan Ochoa (hernan@ampliasecurity.com)
    Use -h for help.



    As you can see, these tools dump logon sessions and display the username, domain/workgroup name and LM/NT hashes very similarly to SAM hashes dump tools output. The main difference is that these tools display the domain/workgroup name as domain users can be logged onto the system too as opposed to the user ID field shown by pwdump-alike tools.
    The following screen-shot demonstrates the successful dump too:

    Dump of logon sessions with Windows Credentials Editor (WCE) on a Windows Server 2003 R2 machine where the Administrator is logged to the console, two users are logged remotely via RDP and one service is running as local user

    I realized during my tests that regardless of the method used to close a session, the logon sessions remain in memory. Take RDP connections, either if you disconnect (clicking on the top right X button of your RDP client) or log off from the Start menu, they remain in memory. I have seen this happening on Windows Server 2008 R2 Enterprise Service Pack 1 too. The main difference being that on Windows Vista onwards the logon sessions are erased from memory a few minutes after the user has logged off.

    The following screen-shots demonstrate the described behaviour:

    Dump of logon sessions following a disconnect via RDP of one user, foobar – his logon session remains in memory

    Dump of logon sessions following a forced log off of user’s foobar RDP connection – his logon session remains in memory

    db2admin logon session also remains in memory despite the relevant services are stopped.

    Threats posed by logon sessions

    The scenario here is similar to LSA secrets dump and cached domain logon information: you are Local System on a machine part of one or more Windows domains and you want to takeover the domains. There are no traces of domain users’ credentials from LSA secrets and the machine does not cache domain logon information.

    To extend your control over the domain you can dump the logon sessions. If there is a logon session of a domain administrator, it is game over: impersonate that logon session to spawn a command prompt. This technique is also known as pass-the-hash or logon session stealing.

    The command line would look like:

    C:\>wce.exe -s <user>:<domain>:<LM hash>:<NT hash> -c cmd.exe

    In the new command prompt window, connect over SMB, for instance with Sysinternals’ PsExec, to the root domain controller to takeover the Windows domain – Windows will use the impersonated NTLM credentials to authenticate against the domain controller and access will likely be granted as you are now, as a matter of facts, the domain administrator.

    Alternatively, if there are no domain administrators’ logon sessions, you can still spray the dumped logon sessions’ hashes to others machines of the domain exactly the same way you do to verify password reuse across machines with the local users’ password hashes: in the event that you have dumped domain users’ logon sessions, chances are high that these users are allowed to login to others systems of the network therefore you have an easy way into these.

    These systems might be vulnerable to others threats that allow you to takeover the domain from there, so it is definitely worth a try.


    Phần 6: Xác thực qua lớp mạng:

    Network services authentication credentials
    Like LSA secrets, Windows stores passwords in a reversible format elsewhere.
    When you login to a network resource like a network share, a proxy server behind NTLM authentication, a database management system, a mail server, etc, you can often instruct your client to save the password, typically by simply ticking the box “Remember my password”.
    Behind the scenes, Windows stores this information in the Credential Manager – a single sign-on (SSO) solution that exists since Windows XP. These stored credentials are used to authenticate each time the corresponding network resource is accessed by the user without the need to retype the password.
    These passwords are encrypted using the DPAPI syubsystem and can be dumped in clear-text format.
    You can also view, edit and add to this password storage. On Windows Vista onwards the Credential Manager is available under Control Panel\User Accounts and Family Safety\Credential Manager or from Control Panel\User Accounts and Family Safety\User Accounts\\Manage your credentials.
    Another storage used by Windows for a similar purpose is the Protected Storage. Applications like Internet Explorer and Outlook Express store the email account password in this storage, where they do not opt to store in the Credential Manager. The passwords stored in the Protected Storage are encrypted using the CryptoAPI functions and the key is derived from the user’s password therefore they can be dumped in clear-text format too.

    Third-party software like Chrome, RealVNC Client, Thunderbird and others store passwords to websites in their own format. Some tools store them within the registry, some use the Windows API and store them in the Credential Manager or the Protected Storage and others in files. Regardless, all these credentials are stored in a reversible format, publicly documented or not, they can be dumped in clear-text like Credential Manager and Protected Storage passwords.

    Dump Credential Manager
    The methods to interact with the Credential Manager is documented by Microsoft and implemented in a number of tools able to dump these credentials.
    NirSoft’s Network Password Recovery (netpass) is my first choice. It is one-executable only tool and reliable. Make sure you run the 64-bit version on 64-bit architecture.
    Cain & Abel can also dump the Credential Manager efficiently, however it only works locally not remotely so you should better avoid it unless installing new software is permitted onto the target machine.
    Passcape’s Network Password Recovery, not to be confused with the namesake tool from NirSoft, also works well, but the trial version only displays the first three characters of the dumped passwords.
    Avoid Metasploit own post-exploitation module windows/gather/credentials/enum_cred_store – it has always crashed regardless of the target Windows version.
    Dump Protected Storage
    NirSoft’s Protected Storage PassView (pspv) is my first choice. It is one-executable only tool and reliable.
    Another tool to consider is carrot, a bundle of other tools (primarily from NirSoft), good to dump Protected Storage credentials.
    Avoid fgdump as it fails to dump the protected storage.

    Dump third-party software stored credentials

    NirSoft has a vast collection of tools to dump third-party software stored credentials. Many of these are bundled in one-executable only tool, carrot.

    If you have got a Meterpreter shell onto the target system, Metasploit is handy to dump third-party software stored credentials as it has numerous post-exploitation modules for this purpose. Some are pretty much reliable, others are in beta and often crash.

    Threats posed by network services authentication credentials
    During an internal infrastructure assessment it is likely that you are able to own a workstation before a server.
    When this occurs, collecting information about what is the role of the machine within the infrastructure is a crucial step to successfully compromise the overall network. In cases where the machine is an employee’s workstation used daily, chances are very high that he uses it to access his corporate email, internal web sites, corporate proxy and other services. If so, chances are even higher that the user has ticked the “Remember my password” entry, everywhere.
    Having access, even as a low-privileged user, to these corporate systems “for free” is priceless and useful in your run to extend your control over the network and demonstrate to the customer how even the average and most insignificant workstation far from the DMZ need to be taken care of systematically.
    Often corporate email credentials, network shares passwords and others are reused by users across different services if not the domain user account too so being able to dump the credentials in clear is high value during a penetration test.


    Phần 7: Nhận được dữ liệu trên DNS trong SQL

    We have recently implemented data retrieval over DNS in sqlmap. This data exfiltration technique adds up to the six existing techniques already implemented: boolean-based blind, time-based blind, full UNION, partial UNION, error-based and stacked (nested) queries. It is supported on Oracle (running either on UNIX/Linux or Windows) and Microsoft SQL Server/MySQL/PostgreSQL (running on Windows).
    The technique can be tested for and used by providing sqlmap with the –dns-domain switch following a hostname that resolves over the Internet to the machine where you are running sqlmap from – you do not need to run your name server daemon so you can use a freely available DynDNS or similar solutions: sqlmap starts a fake DNS server on 53/udp so you need to run it with uid=0 privileges and handles the DNS requests from the target DBMS (actually from the DMZ’s DNS server misconfigured to resolve Internet hostnames) automatically.
    In cases where the target parameter is vulnerable and exploitable by either of the blind techniques or both of them, then sqlmap will test for DNS exfiltration too and prefer it over the blind techniques as it is much faster. Needless to say that both error-based and UNION based techniques are preferred if identified exploitable.
    The paper and slide-deck presented recently at PHDays conference in Moscow, Russia are available on my fellow sqlmap developer’s Slideshare page:

    I recommend you all run always sqlmap latest development version from its Subversion repository:

    svn checkout https://svn.sqlmap.org/sqlmap/trunk/sqlmap sqlmap-devcd sqlmap-devpython sqlmap.py –h

    Phần 8: 125 Công cụ bảo vệ hệ thống máy tính:

    The top 125 computer security tools

    The security community has spoken! About 3,000 people have rated the best and most widely used computer security tools. The Nmap project has collected the results of their survey in a relaunched version of their SecTools.org project: Top 125 Network Security Tools.

    sqlmap has made it to place #30 overall: a great result considering that it is a two-developers only project driven by passion, developed in our own spare time and with a large community of supporters, testers and enthusiasts.

    The previous SecTools.org survey was dated 2006, when sqlmap project was just started and unknown to the most. In five years the tool has evolved from a few hundred of lines of code to a massive python tool, versatile and powerful. The security community has acknowledged this: it is the only tool in the list to combine SQL injection detection, data analysis and database takeover capabilities against numerous database management systems despite a lot of others similar tool have been developed throughout the years.

    I found particularly interesting that many people highly rated web proxies in the web scanners category: 3 of the top 5 tools are web proxies. I read it as a positive sign: it means to me that manual testing is the preferred way by many to perform web application assessments as opposed to fully automated web scanners that, for the sake of clarity, can not cover business logic flaws by their design nature, hardly identify session management issues and struggle with multiple user levels’ access control list enforcement verification.

    The #1 tool in the category is Burp Suite, a tool that I use on many web application and web service penetration testing engagements. A tool that eases and assists me in the process of carefully and manually assessing the security of web applications. Congratulations to Dafydd Stuttard for his great work!

    sqlmap scored 6th place in this category, ahead of several commercial web scanners backed by big companies and developed by dozen of people. People could argue that this is because sqlmap is free so more people have access to it, fair point. I like to think that it scored high also because it addresses one single web application vulnerability type, the most critical, and does it damn well in the right hands. On top, we have added a lot of features, takeover functionalities, coverage for many database management systems and several optimizations.

    Out of 11 tools in the sploits category, sqlmap was rated 4th: another great result in my opinion. Like Metasploit framework (#1 of the category) and w3af (#3 of the category), it is open source. It’s the only niche tool focusing on exploiting SQL injections, database design flaws and their mis-configurations against a variety of database software.

    sqlmap would not be the great tool that it is today without its users’ base. I want to thank everyone that have contributed during the last five years with moral support, detailed feedback, overly appreciated patches, bug reports and acclaiming it publicly as a very handy and valuable tool.

    Greetings also to the authors of renowned books for citing and reviewing sqlmap. These include the recently revamped The Web Application Hacker’s Handbook and SQL injection attacks and defense.


    Tham khảo:


    Video demo: http://mdsec.net/labs/demo.html

    Làm thế nào để đồng bộ Active Directory Sync trong khi Username và Password bị mã hoá theo OS 32/64bit ?

    Part 1. Password Filter for OS



    I.      Password Filters. 1

    1.    Password Filter Functions. 2

    2.    Password Filter Programming Considerations. 2

    3.    Installing and Registering a Password Filter DLL. 3

    To install and register a Windows password filter DLL. 3

    II.     Enforce Custom Password Policies in Windows. 4

    III.        Configuring Security Policy. 5

    IV.       The RegEx Password Filter Sample. 6

    V.    Installing the Password Filter 8

    VI.       Source Code Compiler by VC++. 9

          Download boots link: 9

          Error when Building: 9

          Installation. 9



    I. Password Filters

    Password filters provide a way for you to implement password policy and change notification.

    When a password change request is made, the Local Security Authority (LSA) calls the password filters registered on the system. Each password filter is called twice: first to validate the new password and then, after all filters have validated the new password, to notify the filters that the change has been made. The following illustration shows this process.


    Password change notification is used to synchronize password changes to foreign account databases.

    Password filters are used to enforce password policy. Filters validate new passwords and indicate whether the new password conforms to the implemented password policy.

    For an overview of using password filters, see Using Password Filters.

    For a list of password filter functions, see Password Filter Functions.

    The following topics provide more information about password filters:


    1.  Password Filter Functions

    The following password filter functions are implemented by custom password filter DLLs to provide password filtering and password change notification.




    Indicates that a password filter DLL is initialized.


    Indicates that a password has been changed.


    Validates a new password based on password policy.


    2.  Password Filter Programming Considerations

    When implementing password filter export functions, keep the following considerations in mind:

    • Take great care when working with plaintext passwords. Sending plaintext passwords over networks could compromise security. Network “sniffers” can easily watch for plaintext password traffic.
    • Erase all memory used to store passwords by calling the SecureZeroMemory function before freeing memory.
    • All buffers passed into password notification and filter routines should be treated as read-only. Writing data to these buffers may cause unstable behavior.
    • All password notification and filter routines should be thread-safe. Use critical sections or other synchronous programming techniques to protect data where appropriate.
    • Password notification and filtering take place only on the computer that houses the account.
    • All domain controllers are writeable, therefore password filter packages must be present on all domain controllers.

    Windows NT 4.0 domains: Notification on domain accounts takes place only on the primary domain controller. In addition to the primary domain controller, the password filter packages should be installed on all backup domain controllers to allow notifications to continue in the event of server role changes.

    • All password filter DLLs run in the security context of the local system account.

    For information about


    How to install and register your own password filter DLL.

    Installing and Registering a Password Filter DLL

    The password filter DLL provided by Microsoft.

    Strong Password Enforcement and Passfilt.dll

    Export functions implemented by a password filter DLL.

    Password Filter Functions


    3.  Installing and Registering a Password Filter DLL

    You can use the Windows password filter to filter domain or local account passwords. To use the password filter for domain accounts, install and register the DLL on each domain controller in the domain.

    Perform the following steps to install your password filter. You can perform these steps manually, or you can write an installer to perform these steps. You need to be an Administrator or belong to the Administrator Group to perform these steps.

    clip_image002To install and register a Windows password filter DLL

    1.       Copy the DLL to the Windows installation directory on the domain controller or local computer. On standard installations, the default folder is \Windows\System32. Make sure that you create a 32-bit password filter DLL for 32-bit computers and a 64-bit password filter DLL for 64-bit computers, and then copy them to the appropriate location.

    2.       To register the password filter, update the following system registry key:

    4.     SYSTEM
    5.        CurrentControlSet
    6.           Control

    If the Notification Packages subkey exists, add the name of your DLL to the existing value data. Do not overwrite the existing values, and do not include the .dll extension.

    If the Notification Packages subkey does not exist, add it, and then specify the name of the DLL for the value data. Do not include the .dll extension.

    The Notification Packages subkey can add multiple packages.

    7.       Find the password complexity setting.

    In Control Panel, click Performance and Maintenance, click Administrative Tools, double-click Local Security Policy, double-click Account Policies, and then double-click Password Policy.

    8.       To enforce both the default Windows password filter and the custom password filter, ensure that the Passwords must meet complexity requirements policy setting is enabled. Otherwise, disable the Passwords must meet complexity requirements policy setting.



    II.                Enforce Custom Password Policies in Windows


    Most people take the easy way out and use the default filter in order to validate passwords. But did you know you can employ authentication modules to customize your password policies to reflect your organization’s unique security requirements? Find out how in this article.

    by Yevgeny Menaker

    Microsoft Windows allows you to define various password policy rules. Specifically, it allows you to enable the “Password must meet complexity requirements” setting using the Policy Editor. This validates user passwords against password filter(s) (system DLL(s)). Usually, people use the default filter. However, many admins say they’d prefer a Linux-style validation, which would allow them to install various pluggable authentication modules (Linux-PAM modules) to filter user passwords (authentication tokens). You can easily adapt these modules to reflect your organization’s security policy with help of Linux configuration text files. The ability to add-on such modules creates more flexibility in composing password policies. With help of such custom modules (of course, these modules should be developed by a Linux programmers), Linux administrators may even author a regular expression for matching user passwords. Go to www.kernel.org/pub/linux/libs/pam/ for more detailed information about Linux-PAM and the available modules.


    The Linux model described above may be employed on Windows machines as well.

    What You Need: Windows NT/2000/XP

    In this article, learn how to create a
    Custom Password Filter (DLL in C++) that validates passwords against a configurable regular expression. The RegEx functionality is implemented based on the Boost open source library because it has wide support for regular expressions.

    Let’s start with an overview of the Windows Security system.

    Windows Security
    Windows Security is a policy-based system with a set of rules that compose security settings for a local machine or domain. The work of policy-based systems usually has three major stages:

    1. Creating rules to compose a policy.
    2. Searching for evidences.
    3. Enforcing policy based on the evidences.

    There is a parallel between the above stages and real-life legal systems. Most countries have an authority (usually parliament or senate) that makes laws. This corresponds to the first stage—composing the policy). Police departments are the guards of the legal system, responsible for collecting evidence (e.g. measuring car speed on highways) and enforcing the existing laws based on evidences (e.g. canceling driving license in case of exceeding the speed limit). So, a police force corresponds to the second and third stages.

    In Windows security, system administrators play the role of parliament. They dictate the policy for an organization domain. In some cases, regular users also design security policy (e.g. when choosing their own passwords). The police uniform is given to the local security authority (LSA) Windows sub-system. LSA collects evidences for decision-making and enforces the policies (laws). The LSA sub-system is represented by the lsass.exe Windows process and several system DLLs.


    III.             Configuring Security Policy

    System Administrators are usually responsible for configuring Security Policy. Since this article is about password filters, I’ll use configuring Password Policy as the example.




    Figure 1. The “Local Security Policy” Management Console: This shows the list of security settings that compose your password policy on the local machine.


    As mentioned previously, regular users are involved in composing security settings when they choose their own log-on passwords. However, because a weak password can create vulnerable system and compromise organization security, system administrators need more control over this issue and disallow the use of too simple, short and vulnerable to dictionary attacks passwords. In other words, you need to compose a password policy that meets your organization’s security requirements.

    To edit security policies, you can use either the secedit.exe command line utility or the “Domain Security Policy” graphical console available from Control Panel -> Administrative Tools on the domain controller machine. With this tool, you will govern the security policy for all the computers in the Windows domain. Note that in case of workstation machine, only the “Local Security Policy” console is installed (shown in Figure 1). Local policy affects settings on the local machines and it doesn’t override domain policy. Thus, the security settings will be effective for local machine users, but not for domain users. This article uses the graphical tool to alter security settings on the local machine.



    Figure 2. Editing Password Policy Rules: Double-click the “Minimum password length” item to display the dialog window.


    The left pane of the management console contains an Explorer-like tree. Each node represents a different Security Policy. In this example, you’ll make modifications to the Password Policy to require users to choose long enough passwords (at least 10 characters). Here’s how to do it:

    Expand the “Account Policies” node and select “Password Policy.” On the right pane of the management console, you should see a list of security settings (rules) that compose the password policy as shown in Figure 1. Double-click the “Minimum password length” item to display the dialog window (Figure 2). Edit the text field, setting the minimum password length to 10 characters, and click OK.

    Congratulations! The new rule is ready. From now on, LSA will not allow your users to choose passwords shorter than 10 characters.

    An interesting rule from the Password Policy set is “Password must meet complexity requirements.” This rule may be either Disabled or Enabled. In the Disabled state it has no effect. Enabling this rule instructs LSA to validate each password against Password Filters. If you don’t provide any filter, the default is used (which is considered relatively strong). However, the default allows simple passwords, such as Paris123. You definitely want more powerful filters and this is where Custom Password Filters can be helpful.

    What Is a Password Filter?
    A Password Filter plays a primary role in decision-making regarding user passwords. By definition, a Password Filter is a system DLL that exports three functions with the following prototypes (note the
    calling convention):

    BOOLEAN __stdcall InitializeChangeNotify(void);     // (1)

    BOOLEAN __stdcall PasswordFilter( // (2)

    PUNICODE_STRING AccountName,



    BOOLEAN SetOperation


    NTSTATUS __stdcall PasswordChangeNotify(    // (3)


    ULONG RelativeId,



    How does LSA interact with Custom Password Filters by means of the above interface? First, assume that the “Password must meet complexity requirements” rule is Enabled. On the system startup, LSA loads all the available Password Filters and calls the InitializeChangeNotify() function. When LSA receives TRUE as a return value, this means that the Password Filter loaded successfully and functions properly. Upon this call, LSA also builds a chain of available Password Filters (those that returned TRUE).

    When you’re giving a password to a new user or modifying an existing user’s password, LSA assures that every link in Password Filters Chain is satisfied with a new password. LSA invokes the PasswordFilter() function of each filter in the chain. If one filter in a chain returned FALSE, LSA does NOT continue calling the next filter. Instead, it asks the user to provide another password. If every call to PasswordFilter on every filter returns a TRUE value, a new password is approved and each filter is notified about it through the PasswordChangeNotify() function.

    As you can see, the Password Filter is a handy tool for LSA (or, the Windows Police), acting as a speed trap for highway patrol, helping to collect evidence from the “field.” These evidences are useful in the third stage, where policies are enforced.

    Before You Implement…
    Consider the following issues before you start coding your own Password Filters:

    *       Treat sensitive data carefully. The PasswordFilter and PasswordChangeNotify functions receive passwords in clear-text format. These passwords should be processed fast and shouldn’t leave any trails in your memory for malicious applications to capture. Introduced in Windows 2003, the SecureZeroMemory Win32 API cleans specified memory. Traditional ZeroMemory may be not enough, since “smart” compilers will optimize your code and remove calls to this API. To make sure there are no such “useful” optimizations, read a random byte from a password string after it was filled with zeros.

    *       Make your filters fast and efficient. When LSA calls into the Password Filter function, most Windows processing stops, so make sure you don’t perform any lengthy operations.

    *       Expect the unexpected. Because LSA loads password filters during start-up, if something goes wrong, your system may become inoperable or go into deadlock. To avoid this, develop and test your DLLs on machines that have at least two operating systems installed. I have Linux and XP on my box and I found it highly useful when preparing this article. When I encountered problems, I booted from Linux and deleted the Password Filter DLL.

    *       Log your actions. Password Filters run in the context of the lsass.exe process. I don’t recommend debugging this process, because after you close the debugger and end the process, your system will shutdown. The best way to debug your already-running filter is to write the log files to disk and follow them to fix the bugs.

    *       Pre-debug your DLL. While lsass.exe debugging is not recommended, you may test your fresh Password Filter by writing a small unit-test program. In this program, load your DLL with a call to LoadLibrary Win32 API and invoke exported functions (after getting their addresses within GetProcAddress Win 32 API calls). This way, you may check that your filter doesn’t crash and functions properly.


    IV.            The RegEx Password Filter Sample

    Now that you’re aware of all the possible pitfalls, it’s high time for code action. This section will walk you through the sample provided with this article. I’ve created a VS7 solution with the PasswordFilterRegEx VC project.

    As the Password Filter definition requires, you export three functions. Here’s the code for the DEF file included within the sample project:

    LIBRARY PasswordFilterRegEx







    The PasswordFilterRegEx.cpp contains source code for the exported functions. The implementations of InitializeChangeNotify and PasswordChangeNotify are quite simple:

    // Initialization of Password filter.

    // This implementation just returns TRUE

    // to let LSA know everything is fine

    BOOLEAN __stdcall InitializeChangeNotify(void)



    return TRUE;


    // This function is called by LSA when password

    // was successfully changed.


    // This implementation just returns 0 (Success)

    NTSTATUS __stdcall PasswordChangeNotify(


    ULONG RelativeId,





    return 0;


    The bulk of the work is done in the PasswordFilter function (shown in Listing 1). First, create a zero-terminating copy of a password string and assign it to an STL wstring object (STL is used in conjunction with the boost regex library):

    wszPassword = new wchar_t[Password->Length + 1];

    if (NULL == wszPassword)


    throw E_OUTOFMEMORY;


    wcsncpy(wszPassword, Password->Buffer, Password->Length);

    wszPassword[Password->Length] = 0;

    WriteToLog(“Going to check password”);

    // Initialize STL string

    wstrPassword = wszPassword;

    Next, the regular expression is instantiated. The sample Password Filter reads the regular expression from the RegEx value of the following registry key:


    If the value is not found in registry, the dummy default regular expression (“^(A)$”) is used.

    Finally, validate the password against the regular expression and return the results to the caller (LSA):

    WriteToLog(“Going to run match”);

    // Prepare iterators

    wstring::const_iterator start = wstrPassword.begin();

    wstring::const_iterator end = wstrPassword.end();

    match_results<wstring::const_iterator> what;

    unsigned int flags = match_default;

    bMatch = regex_match(start, end, what, wrePassword);

    if (bMatch)


    WriteToLog(“Password matches specified RegEx”);




    WriteToLog(“Password does NOT match specified RegEx”);


    . . .

    return bMatch;

    Just before you return the results to LSA, perform memory clean-up:

    // Erase all temporary password data

    // for security reasons

    wstrPassword.replace(0, wstrPassword.length(), wstrPassword.length(),



    if (NULL != wszPassword)


    ZeroMemory(wszPassword, Password->Length);

    // Assure that there is no compiler optimizations and read random byte

    // from cleaned password string


    wchar_t wch = wszPassword[rand() % Password->Length];

    delete [] wszPassword;

    wszPassword = NULL;


    return bMatch;


    V.              Installing the Password Filter

    Note: In order to filter passwords for domain users, you should use the “Domain Security Policy” console on domain controller machine and install there your password filter. In this example, the entire configuration is done on the local machine. Hence, Password Filter will validate passwords for my local machine accounts. Follow this procedure to activate your fresh Password Filter (the same procedure is applicable for the domain controller):

    *       Enable the “Password must meet complexity requirements” rule of the Password Policy.

    *       Copy the Password Filter DLL to the %SystemRoot%\system32 folder on your machine.

    *       Open the Registry Editor (regedit.exe) and locate the following registry key:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

    *       Modify the “Notification Packages” multi-string value of the above key and add your Password Filter file name without the “.dll” extension. Add the PasswordFilterRegEx string as shown in Figure 3.



    Figure 3. Editing “Notification Packages”: Add the PasswordFilterRegEx string.


    *       Close Registry Editor and restart your machine.

    Your Password Filter in Action
    After you’ve installed Password Filter and restarted your machine, you’re ready for testing. The source code includes a simple regular expression for testing purposes. Find it in the
    RegEx value of the HKLM\Software\DevX\PasswordFilter key (the PasswordFilter.reg
    file is provided with the code for your convenience):


    In other words, start with letters, have some digits in the middle and end up with letters again. This regular expression is not recommended as a strong Password Regular expression, but it is useful for assessing whether your Password Filter does its job.



    Figure 4. Creating a New User: Select Expand Local Users and Groups, right-click on the Users node, and choose the New User menu item.


    Remember that this filter stands after the default Windows filter in the chain. So, in order to have any effect, you’ll need tougher requirements than the default. The Paris2003 password will validate against the default filter, but the test regular expression won’t match it. To check this, create a new user. If you use Domain Controller, create a user with Active Directory. On the stand-alone Workstation machine, right-click on My Computer and choose the Manage item from the context menu. Select Expand Local Users and Groups, right-click on the Users node, and choose the New User menu item as shown in Figure 4.

    Fill-in the new user’s details and assign a password. Try a simple one (e.g.: Paris2003) and you will get an error message from LSA (Figure 5). Try a different, more complex password (e.g.: Paris2003A) and it will be accepted.

    The Secret Is Out
    While there are several commercial products that implement Password Filters, it isn’t really all that difficult. Now, that you understand how they work, you can provide your own, customized solution.



    Figure 5. Error!: This password doesn’t meet the complexity requirements.







    VI.            Source Code Compiler by VC++


           Download boots link: http://nchc.dl.sourceforge.net/project/boost/boost/1.50.0/boost_1_50_0.zip


           Error when Building:

    I writed project which uses <boost/thread/locks.hpp>, i added include directory to Additional Include directories, and lib folder to linker. But when i try to build solution, error:

    Error 1 error LNK1104: cannot open file ‘libboost_thread-vc100-mt-sgd-1_50.lib’

    I searched this file in lib directory, but no file with this name in lib directory. I found file with similar name libboost_thread-vc100-mt-gd-1_50.

           Answer: i built them by guide boost.org/doc/libs/1_50_0/doc/html/bbv2/installation.html


    To install Boost.Build from an official release or a nightly build, as available on the official web site, follow these steps:

    1.     Unpack the release. On the command line, go to the root of the unpacked tree.

    2.     Run either .\bootstrap.bat (on Windows), or ./bootstrap.sh (on other operating systems).

    3.     Run

    ./b2 install –prefix=PREFIX

    where PREFIX is a directory where you want Boost.Build to be installed.

    4.     Optionally, add PREFIX/bin to your PATH environment variable.

    If you are not using a Boost.Build package, but rather the version bundled with the Boost C++ Libraries, the above commands should be run in the tools/build/v2 directory.

    Now that Boost.Build is installed, you can try some of the examples. Copy PREFIX/share/boost-build/examples/hello to a different directory, then change to that directory and run:


    A simple executable should be built.

    1 cách can thiệp AD dễ dàng: Excel mẫu dữ liệu và Macro VB Code chạy tính năng Add bulk user Account trong Windows AD.

    File Excel: user_new.xls


    Dòng 3: Mầu vàng là phần sẽ nhập dữ liệu thay đổi.

    Dòng 1, 2 là dòng tiêu đề của Fields và số thứ tự trong Code (không được thay đổi).

    Đây là code chỉ dùng để nhập, tạo account mới. Không dùng để update cập nhật những thay đổi sau khi đã tạo account.

    Sau khi nhập dữ liệu cho AD,

    Bấm Macro để chạy : Ctrl + Shift + A hoặc để sửa:excel_ad_2


    Để sửa code: hãy chọn tên Macro : AD , sau đó bấm Edit:


    Hãy mở Macro VBA Chỉ nên sửa đoạn code sau:excel_ad_4

    strSheet =”C:\PS\user_new.xls” ‘ vị trí thư mục và tên file excel dùng để lưu và tạo account AD

    strContainer = “OU=student,” ‘có thể thay tên của OU gốc nếu máy chủ AD quan lý với tên khác

    ví dụ: Trường K-12 dùng cấu trúc sau:


    Có tới 4 cấp: nếu muốn đưa Account vào tận cấp thứ 4 thì phải thay OU như sau:

    strContainer = “OU=staff,OU=ThaoDien,OU=Computers,OU=Laptop,”

    Chúc các bạn thành công trong quản lý người dùng với Active Directory và Domain Controller.

    Cách dùng công cụ đồng bộ AD với Outlook Live của Office 365

    Directory Synchronization (DirSync).

    See with DirSync everything in the connected on-premises forest is synchronized to the cloud.


    Activating Dirsync.

    1. Go to https://portal.microsoftonline.com.
    2. Log on using your administrator credentials.
    3. On the Office 365 portal, click the Admin tab


    4. On the Admin portal, click Users.

    5. On the Users page, click Activate next to Active Directory synchronization. Synchronization is deactivated by default.

    6. Activating DirSync launches the Set up Active Directory synchronization roadmap. The page provides a list of DirSync implementation considerations and action items. From this page, review the prerequisites, prepare the domain, and install and configure Identity Federation.


    Installing the Active Directory Synchronization Tool.

    This section discusses how to install the tool and enable it in your cross-premise environment.

    *Note The Active Directory Synchronization Tool must be installed on a 32-bit machine that runs Windows Server 2003 Service Pack 2 or greater.This is change soon but for now this is required.

    To install DirSync:
    1. Go to https://portal.Microsoftonline.com and log on with your administrator credentials.
    2. Click the Admin tab.
    3. On the Admin portal, click Users.
    4. Under Install and configure the Directory Synchronization Tool, click Download.

    5. Save files locally to the computer.
    6. Double-click the downloaded .msi file and click Next.

    7. On Microsoft Software License Terms, click I accept the Microsoft License Terms, and then click Next.


    8. On Select Installation Folder, click Next.

    9. Installation displays installation progress.

    10. Select the Start Configuration Wizard now check box, and click Finish to launch the configuration wizard.

    That’s it you can either wait the 3 hours until next sync or force a synchronization event.

    Force Sync.

    1. Open the directory structure below and double-click on ‘DirSyncConfigShell.psc1’. This will open powershell.



    Check Directory Sync.

    1. Open the admin portal and on the left column select ‘Users’.

    2. Here you should see the double-arrows indicating that these are sync’d users. To delete these users you must delete them from Active Directory.