Category Archives: Service Principal Names

Phần 2. Triển khai cấu hình đăng nhập 1 lần SSO giữa Moodle và AD server – ROBUSTA Distance Learning 2015


10. Cấu trúc hệ thống đăng nhập 1 lần – SSO:

1. Đăng nhập một lần (SSO – Single Sign On): Khi người dùng đăng nhập lần đầu vào một WBT, tài khoản đăng nhập đó sẽ tự động được sử dụng cho phiên làm việc của người đó trong toàn bộ hệ thống.

Hệ thống đào tạo ở đây được hiểu là tập hợp các ứng dụng khác nhau có thể được dùng thông qua giao diện Web. Cơ chế này có thể xây dựng dựa vào một điểm chứng thực trung tâm (Central Authentication Service – “CAS”), dựa vào giao thức LDAP (Lightweight Directory Access Protocol), hoặc hoặc thậm chí dựa vào cookie của trình duyệt để giữ xác thực.

image

image

 

2. Sơ đồ đăng nhập 1 lần với LMS vs LCMS:

screenshot_technologists_03 image

3. Khả năng đáp ứng đăng nhập 1 lần với các ứng dụng hiện nay:

image

image

4. Khả năng tích hợp giữa e-learning với các mô hình hệ thống dịch vụ khác:

image  

Dựa trên các phân tích và thực tế triển khai, phát triển sản phẩm công nghệ đào tạo trực tuyến hiện nay, chúng ta thấy được Moodle là một trong các mô hình E-learning phát triển mạnh mẽ nhất trên thế giới.

5. Cấu trúc vận hành xác thực trong SSO:

image

Với mô hình cấu trúc xác thực SSO nói trên đã có rất nhiều các gói ứng dụng, giao thức và giải pháp xác thực, đăng nhập 1 lần khác nhau.

Nhưng tất cả đều phải tuân thủ 1 nguyên tắc cơ bản là bảo mật, quản lý và vận hành theo nguồn dữ liệu người dùng đơn giản và hiệu quả nhất.

 

6. Lý do lựa chọn giải pháp tích hợp Moodle với AD Server:

    • ROBUSTA Distance Learning 2015 đã và đang sử dụng hạ tầng quản lý người dùng trên nền Windows Active Directory (AD Server) và tích hợp các nền tảng dịch vụ Office 365 – Exchange – Lync – SharePoint Online, CRM online. Do vậy, việc lựa chọn giải pháp tích hợp đăng nhập 1 lần giữa Moodle và AD là hiển nhiên.
    • Ngoài ra, các hệ thống thực hành Labs trên Private Cloud, Hybrid Cloud, Public Cloud, VMware vSphere đều được kết nối, đồng bộ tài khoản giữa các ứng dụng đó với AD Users.
    • Đây là 1 phần quan trọng để thống nhất quản lý người dùng, đồng thời đem lại sự đơn giản hóa cho người dùng khi sử dụng hệ thống Đào tạo trực tuyến của ROBUSTA.

image

7. Các bước cấu hình đăng nhập 1 lần trên Moodle Admin:

Tham khảo link: https://docs.moodle.org/28/en/Active_Directory#Troubleshooting_AD_and_LDAP_authentication 

Tham khảo link: Tích hợp Moodle với Microsoft Office 365 thông qua AD: http://www.moodlenews.com/2013/integrate-moodle-and-microsoft-office-365-through-ad/ 

Tham khảo link:  Lỗi tích hợp xác thức trên nền IIS http://support.microsoft.com/kb/896861 

Tham khảo link: cấu hình SMTP relay gửi thư qua Office 365 trên windows server 2008 http://www.configureoffice365.com/configure-office-365-smtp-relay/ 

Tham khảo link: cấu hình phân quyền và chức năng sử dụng trong Moodle: https://docs.moodle.org/28/en/Standard_roles 

Tham khảo link: cách xóa quyền truy cập của Guest / Anonymous: https://moodle.org/mod/forum/discuss.php?d=65614

 

8. Chi tiết các bước tích hợp Moodle với AD  thông qua giao thức xác thực LDAP Authentication và NTLM SSO:

Bước 1:  chuẩn bị

– Moodle 2.8 Server đang chạy trên máy chủ Windows Server 2012 đã Join domain.

– 1 máy chủ Domain Control Center “DCC” chạy trên windows server 2008 r2.

Bước 2:  kiểm tra tình trang kết nối LDAP qua cổng 389 từ máy chủ Moodle 2.8 tới máy chủ DCC.

– Bạn nên download công cụ LDP.zip để kiểm tra các công việc trên máy chủ Moodle 2.8

(tham khảo hướng dẫn dùng ldp.exe : https://technet.microsoft.com/en-us/library/cc794810%28v=ws.10%29.aspx ) 

– Giải nén file ldp.zip vào thư mục c:\LDAP trên máy chủ Moodle.

– Chạy file ldp.exe

image

 

– Chọn menu Connection sau đó bấm chọn Connect.

– Nhập tên máy chủ AD server bạn cần để kiểm tra tình trạng làm việc của LDAP. (nếu bạn không chắc chắn tên hoặc ip của máy chủ AD thì hãy nhập dòng lệnh sau:

nltest/dclist:yourdomain.name.com nó sẽ giúp bạn nhìn được danh sách các máy chủ Domain controllers trong hệ thống mạng LAN của bạn.) sau đó bấm OK.

– Nếu mọi thứ thực hiện đúng nó sẽ kết nối và nó sẽ hiển thị tất cả cấu hình LDAP server /phiên bản của máy chủ AD.

image

– Bấm menu ConnectionBind.

– Bây giờ chúng ta cần nhập username, password và domain (nhập tài khoản administrator username và mật khẩu, tên miền domain).

– Nếu thực hiện thành công sẽ thấy xuất hiện Authenticated as dn:’username’. (cần khởi tạo hoặc kiểm tra tài khoản này với quyền admin privileges).

– Chúng ta có thể bấm menu View sau đó chọn popbar  Tree.

– Một menu sổ xuống và bạn chọn BaseDN cho việc hiển thị thông tin trong domain của bạn.

image

– Bạn sẽ nhìn thấy phía bên trái domain của bạn, các thông tin về OU và CN trong máy chủ AD đang quản lý.

– Bước tiếp theo ta sẽ cần dùng các thông tin trong OU, CN và DC để khai báo vào máy chủ Moodle LDAP 

 

Bước 3: kích hoạt Moodle LDAP

– Trước hết chúng ta cần kích hoạt LDAP plugin.

–  Đăng nhập vào Moodle bằng admin, bấm: Site administration, Plugins, Authentication và chọn Manage authentication.

– Trong danh sách các plug-in sẽ thấy kiểu xác thực có giá trị  “available authentication types” ta bấm tiếp vào hình “con mắt”  để kích hoạt “LDAP Server –> enable”.

image

Bước 4: Cấu hình Moodle LDAP:

– Bấm vào LDAP Server để truy cập trang cấu hình LDAP:

  • Host URL: ldap://ip (đây là tên FQDN hoặc IPv4 của máy chủ AD domain controller, nếu  có nhiều máy chủ DC bạn có thể nhập các địa chỉ phân cách nhau bằng dấu;  ví dụ: ldap://10.66.28.42;ldap://10.66.28.43 ).
  • Version: 3  
  • Use TLS: No (bạn có thể nâng cấp dùng TLS sau)
  • LDAP encoding: ulf-8

Bind Settings

  • Hide password: yes (không cho lưu mật khẩu trong Moodle database.)
  • Distinguished Name: CN=LDAP,OU=Other,OU=Admin,OU=School Users,DC=***,DC=***,DC=****,DC=*** (có thể sao chép kết quả từ OU,CN,DC của công cụ ldp.exe).

image

  • Password: ******** (mật khẩu của account admin dùng cho Bind account)

User Lookup Settings

  • User Type: MS ActiveDirectory (đây là kiểm truy cập bằng account LDAP AD User).
  • Context: OU=school users,DC=***,DC=***,DC=***,DC=*** (nặp lại có thể sao chép kết quả từ OU,CN,DC của công cụ ldp.exe).
  • Search Subcontext: Yes (giúp tìm cấc tài khoản theo kiểu nặp lại OU nhiều cấp OU –> OU1 –> OU11).
  • User Attribute: samaccountname (các thuộc tính người dùng để tìm kiếu theo kiểu tên / email có trong cấu trúc cây LDAP user. Thông thường là kiểu domain\username hay còn gọi sAMAccountName hiếm khi có trường hợp đặc biệt kiểu UPN hoặc email address) , Nó thường dùng kiểu: cn (Novell eDirectory and MS-AD) , uid (RFC-2037, RFC-2037bis cho SAMBA 3.x LDAP extension), nhưng nếu bạn dùng MS-AD bạn cần nhớ rằng ta cần phải dùng theo chuẩn đăng nhập NTLM SSO nên thường dùng sAMAccountName (là kiểu đăng nhập The pre-Windows 2000 logon account name).

Force Change Password

  • Force Change Password: no (Chúng ta không nên cho user Moodle được phép thay mật khẩu, người dùng có thể thay từ AD server hoặc từ việc đăng nhập computer và dùng tổ hợp phím Ctrl+Alt+Del).

LDAP password expiration Settings

  • Expiration: no (Không nên giới hạn tuổi của mật khẩu ở Moodle LDAP vì sẽ rắc rối lớn nếu người dùng không đăng nhập được Moodle vì mật khẩu truy cập vào Moodle bị hết hạn sử dụng).
  • Grace Login: no (Nếu đã không đăng nhập được Moodle qua mạng thì hiển nhiên họ sẽ không vào được trang My Moodle cá nhân hoặc trang admin Moodle).

Enable User Creation

  • Create User Externally: no (Chúng ta muốn chỉ có những tài khoản thuộc AD mới truy cập được Moodle).

Course Creator

  • Creators: OU=Staff,OU=School Users,DC=***,DC=***,DC=***,DC=*** (nặp lại có thể sao chép kết quả từ OU,CN,DC của công cụ ldp.exe).

NTLM SSO (đây là cấu hình bắt buộc)

  • Enable: yes (cho phép sẽ đăng nhập tài khoản bằng Moodle single sign-on).
  • Subnet: IP/22 (đây là dải địa chỉ IP Subnet address  nhằm cho phép sử dụng truy xuất NTML SSO single sign-on, kiểm soát việc các computer có thuộc dải được phép SSO).
  • MS IE fast path: Yes, attempt NTLM other Browsers (đảm bảm mức tương thích với các phiên bản IE là tối đa).
  • Authentication Type: NTLM.
  • Remote Username Format: %domain%\%username% (default)

Data Mapping

  • First Name: givenname
  • Sure Name: sn
  • Email Address: mail

Tham khảo linK: các trường thông tin dùng trong AD  http://www.kouti.com/tables/userattributes.htm 

image

image

 

Bước 5: Lưu lại những thay đổi:

 

Bước 6: Cấu hình NTML trên IIS Server:

– Tìm đến file trong thư mục sau auth/ldap/ntlmsso_magic.php thông qua IIS Management Console,

    Nếu dùng IIS 6.0 thì bấm phải chuột vào file và chọn properties:

    • Ở tab “file security” bấm quyền truy cập Authentication and Access control chọn nút edit.
    • Bỏ chọn  “Enable Anonymous Access” và bấm chọn “Integrated Windows Authentication”

    Nếu dùng IIS 7.0 thì bấm phải chuột vào file và chọn properties

    • Sau mục chỉ dẫn navigating chọn thư mục ‘auth/ldap’ và bấm chuyển “switch to Content View”.
    • Bấm phải chuột trên file và chọn “Switch to Features View”.
    • Bấm vào biểu tượng Authentication icon nằm cửa sổ bên phải.
    • Chọn ‘Anonymous Authentication’ và  bấm nút ‘Disable’.
    • Chọn ‘Windows Authentication’ và bấm nút ‘Enable’.

    Nếu dùng IIS 7.5  bạn sẽ cần chọn ‘Windows Authentication’ và chọn ‘Providers’. Nó sẽ hiển thị danh sách enabled providers Negotiate and NTLM. hãy chuyển đổi thứ tự để cho NTLM lên đầu danh sách.

    Moodle_SSO

    image

     

    Bước cuối: Thử nghiệm

    – Bấm chọn (Đăng nhập):

    image

    – Nhập domain name\username và mật khẩu của AD:

    image

    – Màn hình tự động đăng nhập Moodle bằng NTML:

    image

    – Bạn sẽ nhận được thư gửi có nội dung và link để kích hoạt tài khoản truy cập sử dụng các dịch vụ của Moodle sau khi khai báo thêm các thông tin về User Profile (đặc biệt là địa chỉ email)

    image

    Tham khảo: Phần 3. Triển khai cấu hình đăng nhập 1 lần SSO giữa AD server On-Premise với Microsoft Office 365 – ROBUSTA Distance Learning 2015

    P.S: Rất tiếc phần 3, chỉ công bố trong chương trình đào tạo MS Office 365, Private Cloud.

    Các bạn hãy đăng ký tham gia các khóa học của http://robusta.vn để được trải nghiệm, hỗ trợ và thực hành tốt hơn.

     

    Chúc các bạn thành công !

    Làm thế nào có thể thay đổi tên miền trong tổ chức doanh nghiệp trên Windows Server 2012?


    Bài toán đặt ra:

    Hệ thống domain của tổ chức Doanh nghiệp thông thường được tạo theo cấu trúc nội bộ, không liên quan tới hệ thống dịch vụ trên Internet. Nhưng vì một số lý do rất cơ bản, tổ chức doanh nghiệp lớn, nằm dải khắp các quốc gia khác nhau.

    Khi dùng chung cấu trúc và tên 1 domain,

    Ví dụ:  Robusta.org , các đơn vị, tổ chức thành viên sẽ dùng lại đúng domain này cho hệ thống nội bộ tại quốc gia thành viên, đây là cách truyền thống, đơn giản, tiết kiệm thời gian.

    Robusta_Org_old

    Sau khi xây dựng các hạ tầng mới tài chi nhánh hoặc các tổ chức doanh nghiệp tại các quốc gia thành viên như: Ảo hóa VMware vCenter, Private Cloud…

    Các chi nhánh và tổ chức danh nghiệp thành viên sẽ nảy sinh vấn đề mới đó là:

    1. Không thể copy sao chép giống y nguyên domain name của Head quarter do vấn đề conflic về tên miền, quản lý tên miền khi các chi nhánh có nhu cầu Public các dịch vụ Web Portal, Intranet, Private Cloud, Mobile Application cần có chữ ký số thuê của các hãng Cert Sign, Godaddy…
    2. Tên miền quản lý do Head quarter quản lý do vậy, khi đăng ký SSL/TLS sẽ phải do Admin IT của Head quarter control rất mất thời gian hoặc không chủ động điều khiển được từ phía chi nhánh, tổ chức thành viên.
    3. Các chi nhánh, tổ chức thành viên khi có đầu tư hạ tầng thường sẽ có các cơ cấu nhân sự, quản lý tài nguyên chủ động, độc lập thậm chí cấu trúc kỹ thuật CNTT khác đi so với cấu trúc ở trên:

     

    Robusta_Org_new

    Theo như mô hình trên đây thì chúng ta sẽ:

    – Dễ dàng quản lý từng domain name cho các chi nhánh hoặc tổ chức doanh nghiệp thành viên mà không bị phụ thuộc vào việc xét duyệt

    đợi điều khiển từ phía Head quarter mỗi lần có phát sinh từ đơn vị chi nhánh.

    – Chủ động quản lý các tên miền, máy chủ, máy trạm, tài khoản người dùng, phân nhóm và đặc biệt là các dịch vụ SSL/TLS đăng ký để public intranet/extranet/internet.

     

    Các phương án thay đổi:

    1. Phương án 1: Xóa Domain tại các chi nhánh hoặc tổ chức Doanh nghiệp thành viên  ( demote AD-DC, sau đó restart và dcpromo lại AD-DC với tên mới)

    • Phương án này đơn giản lặp lại các bước đã làm, mất thời gian làm lại, nhưng có thể sẽ không phù hợp với các máy chủ dịch vụ đã cài và đang vận hành như: UC Voice Lync Conferencing, Exchange Server 2013 on-primise, MS SQL server enterprise, MS SharePoint farm, MS BizTalk Server Enterprise…
    • Do tất cả các máy chủ trên được cài, cấu hình trên nền tảng Windows Authentication, cần Join Domain với tên domain chuẩn ban đầu có sẵn. Nếu hủy domain hiện thời sẽ dẫn tới mất Windows Authentication và WFC Platform cho phép các máy chủ dịch vụ chạy.
    • Phương án này có thể gây sự cố không dùng lại được do các dịch vụ, cấu hình của những ứng dụng phức tạp, ứng dụng đã cấu hình theo tên miền cũ không tương thích, không phù hợp với cấu hình mới.

    2. Phương án 2: Thay đổi tên miền (rename domain, sau đó join domain lại ở các máy chủ, máy trạm)

    – Phương án này đơn giản trải qua hơn 28 bước thay đổi tên miền và join lại cho các máy trong tên miền của chi nhánh.

    – Phương án này sẽ mất thời gian join domain lại các máy chủ dịch vụ, máy trạm với tên miền và tài khoản join domain admin mới.

    – Phương án này sẽ không phải cấu hình lại toàn bộ các ứng dụng dịch vụ đang có, chỉ lưu ý các thông số của các trường hợp sau:

    1. UC Server sẽ phải kiểm tra lại các tài khoản login dịch vụ theo kiểu UPN@domain và sau đó kiểm tra dịch vụ có dùng account domain\username.

    Chứng chỉ CTL sẽ phải xóa bớt chứng chỉ gốc hoặc renew lại chứng thư số mới

    2. MS SQL Server enterprise phải cấu hình quyền access login server và có thể cả quyền DB Admin theo dạng Mixed mode (cho phép account SQL Local “sa”) được phép truy cập MS SQL

    khi gặp sự cố về Domain Controller hoặc thay đổi Domain name dẫn tới các account của domain name cũ điều khiển được MS SQL Server…

    3. MS Exchange server sẽ phải chạy lại Exchange Configuration Wizard để re-buil lại cấu hình domain mới cho Mail Server re-configure

    4. MS SharePoint server sẻ phải chạy lại SharePoint Server Configuration Wizard để re-buil Farm Server và một số cấu hình khác.

    5. Phải backup các GPO của máy chủ AD-DC trước khi rename domain

     

    3. Phương án 3: Không thay đổi tên miền, chỉ thêm các bí danh cho tên miền trên DNS Server (thêm các DNS Zone, bản ghi A (Host), CNAME, PTR, TXT, SRV)

    – Phương án này đơn giản trải qua hơn 3 bước thay đổi các thông số tên máy chủ dịch vụ, mapping IP nội bộ các máy của chi nhánh.

    – Phương án này sẽ mất ít thời gian kiểm tra máy trạm , máy chủ dịch vụ từ ngoài truy cập và hệ thống nội bộ để xác định các hạng mục có chạy ổn định hay không ?

    – Phương án này có thể không phù hợp với toàn bộ hạ tầng ứng dụng của chi nhánh khi có nhiều chuẩn HĐH khác nhau, nhiều chuẩn kết nối dữ liệu người dùng khác nhau, ứng dụng đã fix code gọi LDAP/ADFS…

    – Phương án này chỉ phù hợp với hạ tầng đã hoặc đang triển khai Private Cloud, giúp các các web portal intranet, các ứng dụng Windows Form… có thể kết nối và truy cập qua Internet bằng các trình duyệt web HTML5 smartphone, mobile device mà không cần thiết lập VPN kết nối Site – to – site.

     

    Tóm lại, phương án 2 là hợp lý nhất.

     

    Chi tiết các bước, các bạn nên tham khảo:

    Các bước thay đổi tên miềnhttps://mizitechinfo.wordpress.com/2013/06/10/simple-guide-how-to-rename-domain-name-in-windows-server-2012/ 

    Tham khảo các ghi chú về kỹ thuật thay đổi tên miền: http://technet.microsoft.com/en-us/library/cc738208(v=ws.10).aspx

    Tham khảo support tình huống đăng ký lại chữ ký số mới cho UC: http://support.microsoft.com/kb/2464556/ 

    Tham khảo cách đăng ký chữ ký số cho IIS8, IIS8.5:  https://www.digicert.com/ssl-support/ssl-host-headers-iis-8.htm

    Tham khảo cách đăng ký chữ ký số cho Exchange 2013: http://exchangeserverpro.com/exchange-server-2013-ssl-certificates/

    Configuring SharePoint 2010 with Kerberos Authentication


    Determine the application pool account that will be responsible for authenticating users.

    Follow the steps below to be absolutely sure of the account responsible for running the site that will support kerberos authentication. If SharePoint has already been configured verify your application pool account is, in fact, running the IIS application pool that supports the website where Kerberos is enabled

    image

    Open the web application that will support Kerberos and make a note of the application pool that supports this web application (note that you may have more than one web application for the same data for such cases as http and https so take care to determine the exact web application)

    image

    Make a note of the account that is the identity of this application pool, later this account must be trusted for “Delegation”.

    * If the application pool is “Network Service” then Kerberos cannot be configured, the application pool account configured through Central Administration must be a domain account.

    image

    Get the exact machine names that will host the sites that will support kerberos authentication

    Right mouse key on Computer Management and click properties

    image

    Make a note of the machine’s actual name (you will not be using the alias)

    image

    Open Active Directory Users and Computers

    image

    Open the Application Pool account in Active Directory Users and Computers (ADUC) and note that there is no tab “Delegation”

    image

    Locate the servers(s) in Active Directory Users and Computers as well

    Repeat the step above for the computer, the Delegation tab will typically not be visible until the SETSPN tool is run (that will come later). In the screenshot below, the Delegation tab is visible because the server is an all in one with a domain controller.

    image

    Enable Kerberos for SharePoint Web Application

    First things first, Kerberos can be enabled for an existing SharePoint web application if it was not specified during the initial installation wizard. Follow the steps below to enable kerberos authentication for a SharePoint web application.

    Open central administration, note that the port may be different (I typically use 8080 for central administration) *** NOTE, IF YOU CAN NOT OPEN CENTRAL ADMINISTRATION, DO NOT HAVE RIGHTS, OR DO NOT KNOW HOW THEN STOP, YOU SHOULD NOT BE DOING THIS ***

    image

    Click on Manage Web Applications

    image

    image

    In the dialog that opens, click on the zone (which is typically default although you may choose intranet)

    image

    In the Edit Authentication dialog that opens, scroll down to IIS Authentication Settings and choose “Negotiate (Kerberos)”. A JavaScript alert will appear warning you of the manual steps you will have to complete, these manual steps are detailed later in this article)

    image

    Click save and close the remaining dialogs.

    Run SETSPN command line tool for the SharePoint Application Pool Account

    The enable kerberos authentication a domain administrator will need to run the following commands via command line on each SharePoint Server. These commands use the SETSPN tool which is delivered by default in all Windows Server 2008 machines, if the tool is missing it is readily available for download from Microsoft.com.

    Open a command prompt as administrator

    image

    First run the SETSPN command for the application pool account.

    Correct the names in bold below to match the names in your environment. Also note that the “http“does not have a “://”.

    setspn –A http/servername corp\spapppool

    image

    Run a similar command for each server (the results below are atypical since the machine used is already a domain controller, however, the command is still correct

    setspn –A http/spapp10 spapp10

    image

    Open Active Directory Users and Computers and Trust the Application Pool for Delegation

    Once the SETSPN command has been run, the delegation tab will appear in Active Directory Users and Computers (ADUC) for the application pool account.

    image

    On the delegation tab of the SharePoint Application Pool’s properties window “Trust this user for delegation to any service (Kerberos only)”

    image

    Open Active Directory Users and Computers and Trust the Server(s) for Delegation

    Once the SETSPN command has been run, the delegation tab will appear in Active Directory Users and Computers (ADUC) for the servers registered using the SETSPN tool

    image

    On the Delegation tab check the box “Trust this computer for delegation to any service (Kerberos only)”

    image

    Verifying Service Principal Names (SPNs) using SETSPN

    The setspn tool does support the –L or list switch that allows administrators to display the SPNs for a particular computer or user account.

    Run setspn for the service account

    setspn –L corp\spapppool

    image

    Run setspn for the server

    setspn –L spapp10

    image

    Testing Kerberos

    There are tools available for testing Kerberos but it’s quite easy to determine if it is running properly.

    When it’s enabled but not working the following symptoms may be present

    1. Login prompts may appear when the previously did not under NTLM Authentication
    2. Login Errors appear in the Windows Security Event Log typically stating that Kerberos authentication failed
    3. Users are required to login using Office applications when their machines are domain members and the logged in user should have rights.

    When Kerberos is first configured for the application pool account a message will appear in the Windows Security Logs stating that a ticket was requested.image

    Open SharePoint in a browser using the URL where Kerberos is now configured and then refresh the security log. If Kerberos is running properly messages similar to the one below will appear in the logs on a regular basis.

    For particular users logged in, events will appear similar to the one below

    image

    In addition, many messages similar to the one below will appear in the event log.

    Determine the application pool account that will be responsible for authenticating users.

    Follow the steps below to be absolutely sure of the account responsible for running the site that will support kerberos authentication. If SharePoint has already been configured verify your application pool account is, in fact, running the IIS application pool that supports the website where Kerberos is enabled

    image

    Open the web application that will support Kerberos and make a note of the application pool that supports this web application (note that you may have more than one web application for the same data for such cases as http and https so take care to determine the exact web application)

    image

    Make a note of the account that is the identity of this application pool, later this account must be trusted for “Delegation”.

    * If the application pool is “Network Service” then Kerberos cannot be configured, the application pool account configured through Central Administration must be a domain account.

    image

    Get the exact machine names that will host the sites that will support kerberos authentication

    Right mouse key on Computer Management and click properties

    image

    Make a note of the machine’s actual name (you will not be using the alias)

    image

    Open Active Directory Users and Computers

    image

    Open the Application Pool account in Active Directory Users and Computers (ADUC) and note that there is no tab “Delegation”

    image

    Locate the servers(s) in Active Directory Users and Computers as well

    Repeat the step above for the computer, the Delegation tab will typically not be visible until the SETSPN tool is run (that will come later). In the screenshot below, the Delegation tab is visible because the server is an all in one with a domain controller.

    image

    Enable Kerberos for SharePoint Web Application

    First things first, Kerberos can be enabled for an existing SharePoint web application if it was not specified during the initial installation wizard. Follow the steps below to enable kerberos authentication for a SharePoint web application.

    Open central administration, note that the port may be different (I typically use 8080 for central administration) *** NOTE, IF YOU CAN NOT OPEN CENTRAL ADMINISTRATION, DO NOT HAVE RIGHTS, OR DO NOT KNOW HOW THEN STOP, YOU SHOULD NOT BE DOING THIS ***

    image

    Click on Manage Web Applications

    image

    image

    In the dialog that opens, click on the zone (which is typically default although you may choose intranet)

    image

    In the Edit Authentication dialog that opens, scroll down to IIS Authentication Settings and choose “Negotiate (Kerberos)”. A JavaScript alert will appear warning you of the manual steps you will have to complete, these manual steps are detailed later in this article)

    image

    Click save and close the remaining dialogs.

    Run SETSPN command line tool for the SharePoint Application Pool Account

    The enable kerberos authentication a domain administrator will need to run the following commands via command line on each SharePoint Server. These commands use the SETSPN tool which is delivered by default in all Windows Server 2008 machines, if the tool is missing it is readily available for download from Microsoft.com.

    Open a command prompt as administrator

    image

    First run the SETSPN command for the application pool account.

    Correct the names in bold below to match the names in your environment. Also note that the “http“does not have a “://”.

    setspn –A http/servername corp\spapppool

    image

    Run a similar command for each server (the results below are atypical since the machine used is already a domain controller, however, the command is still correct

    setspn –A http/spapp10 spapp10

    image

    Open Active Directory Users and Computers and Trust the Application Pool for Delegation

    Once the SETSPN command has been run, the delegation tab will appear in Active Directory Users and Computers (ADUC) for the application pool account.

    image

    On the delegation tab of the SharePoint Application Pool’s properties window “Trust this user for delegation to any service (Kerberos only)”

    image

    Open Active Directory Users and Computers and Trust the Server(s) for Delegation

    Once the SETSPN command has been run, the delegation tab will appear in Active Directory Users and Computers (ADUC) for the servers registered using the SETSPN tool

    image

    On the Delegation tab check the box “Trust this computer for delegation to any service (Kerberos only)”

    image

    Verifying Service Principal Names (SPNs) using SETSPN

    The setspn tool does support the –L or list switch that allows administrators to display the SPNs for a particular computer or user account.

    Run setspn for the service account

    setspn –L corp\spapppool

    image

    Run setspn for the server

    setspn –L spapp10

    image

    Testing Kerberos

    There are tools available for testing Kerberos but it’s quite easy to determine if it is running properly.

    When it’s enabled but not working the following symptoms may be present

    1. Login prompts may appear when the previously did not under NTLM Authentication
    2. Login Errors appear in the Windows Security Event Log typically stating that Kerberos authentication failed
    3. Users are required to login using Office applications when their machines are domain members and the logged in user should have rights.

    When Kerberos is first configured for the application pool account a message will appear in the Windows Security Logs stating that a ticket was requested.image

    Open SharePoint in a browser using the URL where Kerberos is now configured and then refresh the security log. If Kerberos is running properly messages similar to the one below will appear in the logs on a regular basis.

    For particular users logged in, events will appear similar to the one below

    image

    In addition, many messages similar to the one below will appear in the event log.

    image

    1 máy PC đã join domain sau khi đăng nhập máy bằng Ctrl + Alt + Delete thì truy cập vào website trong mạng Intranet IIS 7.x theo kiểu Windows Authenticate sẽ phải tự động truy cập vào được bằng Domain User ?


    Vấn đề 1: 1 máy PC đã join domain sau khi đăng nhập máy bằng Ctrl + Alt + Delete thì truy cập vào website trong mạng Intranet IIS 7.x theo kiểu Windows Authenticate sẽ phải tự động truy cập vào được bằng Domain User ?

    Vấn đề 2: Máy chủ hosting website đó là IIS7.5 / Windows Server 2008 R2 SP1. Máy chủ chạy website ASP.NET có cả SharePoint 2007 vậy khi triển khai gói MS Live@edu SSO Kit thì cấu hình SSO như thế nào để máy PC trong Domain Local (đang join domain) sẽ có thể truy cập tự động (không hỏi user/password) khi truy cập site:SSO ?

    Hãy tham khảo bài viết dưới đây:

    IIS and Kerberos. Part 1 – What is Kerberos and how does it work?

    Edit: I’ve created a list of all the parts in this series here, which will be updated as I add more parts.

    Configuring Kerberos and Delegation is one of the more common problems I see in the communities and even within Avanade. Since Kerberos isn’t a simple topic, I’m going to write a quick series explaining how Kerberos works, common scenarios and problems and some troubleshooting tips.

    Kerberos is an open authentication protocol developed at MIT, and implemented in Windows 2000/2003 Active Directory domains (amongst other places). Authentication is the process of proving your identity to a remote system. Your identity is who you are, and authentication is the process of proving that. In many systems your identity is your username, and you use a secret shared between you and the remote system (a password) to prove that your identity.

    The problem with simplistic shared secret systems is two-fold:
    a) there is a scalability problem. If every user needs to maintain a shared secret with every individual server (or every service on every server!) then that results in poor passwords. Users can not be expected to remember dozens, hundreds or thousands of unique passwords and so end up repeating them regardless of whether the server is a low security or high security resource
    b) there is an issue in securely transmitting the shared secret from the user to the server. Various technologies (like TLS/SSL) exist for securing the transport of data between machines, however it is incumbent upon each service to utilise services lower down in the network stack.

    Kerberos is designed to overcome these limitations. In this part we look at how a simple Kerberos implementation works. In this scenario we have a user using a client machine that wishes to connect to a remote service (the user here is a person or application, the client is the OS or machine). Remember that we want a system that allows us to store shared secrets centrally, and to securely transmit user credentials between client and service. Lastly we should look to prevent replay attacks (where someone who is sniffing the wire can replay captured packets to impersonate a legitimate user, even if they do not know how to create the authentication packets themselves).

    To begin with we introduce the Kerberos KDC – Key Distribution Centre. In the Windows Active Directory world, the KDC lives on Domain Controllers (DCs). The client connects to the Authorisation Service (AS) that runs on the KDC and asks the AS to authenticate the user to the remote service. Technically, the client doesn’t need to authenticate itself to the Domain Controller. However in the Active Directory world, something called pre-authentication is used to ensure that the user (or client application) is actually who they say they are.

    Simple Kerberos implementation

    The AS on the KDC generates a session key that will be used by the client and the remote service. It encrypts the session key with the user’s password (this is why the user doesn’t need to authenticate – if the user isn’t who they say they are, they won’t be able to decrypt the session key because they don’t know the user’s password). The KDC also prepares a second piece of data – it again encrypts the session key as well as the user’s username (known as a Kerberos principal), but using the service’s password this time to encrypt the data. Only the remote service will be able to decrypt this second piece of data. This second piece of data is known as the Service Ticket (or just Ticket).

    The KDC now sends both pieces of data back to the client. The user, knowing their own password, is able to decrypt the first piece of data, and extract the session key. The user however does not know the service’s password, so is unable to decrypt the second piece of data. The client uses the session key to encrypt the current time (amongst other things, but they aren’t so important right now). This piece of data is known as the Authenticator. The client sends the Authenticator it just generated, along with the Service Ticket received from the KDC to the remote service.

    The remote service is able to decrypt the Service Ticket using its own password. It is thus able to get access to the session key, and the Principal (user) attempting to connect. It now uses the session key to decrypt the Authenticator, and extract the time. It compares the time to the current system time on the server to ensure a match. Since only the service, the KDC and the user, know the session key then the service can assume that user must be who they say they are.

    If an imposter sent a Service Ticket to the service (e.g. by replaying captured packets) they wouldn’t know the correct session key necessary to encrypt the timestamp correctly. Alternatively, if the imposter attempts to use captured Authenticator packets (which contain a timestamp), thus bypassing the need to know the session key, then the times will not match when the Authenticator is decrypted by the service and the service will refuse to authenticate the remote user.

    If this was the extent of the Kerberos, then each and every time the client received an encrypted session key from the KDC, the user would need to enter their password to allow the client machine access to it. That could rapidly become a productivity sinkhole (imagine having to enter your password for each and every HTTP request you made!). To get around this, the client machine could cache the user’s password, but that isn’t a particulary secure system. What Kerberos does is introduce the concept of a Ticket Granting Ticket (TGT).

    Ticket Granting Tickets are issued by the AS running on the KDC in the same way that a normal service ticket is issued. However the TGT is valid for the Ticket Granting Service, rather than a remote HTTP server (or any other type of server). Whenever the user wishes to connect to a remote service, it can use the TGT that it has already received to connect to the TGS. The TGS, after authenticating the user via the TGT, issues a Service Ticket to the remote service. However instead of encrypting anything using the user’s password, it encrypts using the session key originally generated by the AS. Since the client machine aleady knows this from when the TGT was received in the first place, there is no need to bother the user for their password. The TGT typically has a short lifespan – around 8 hours or so.

    IIS and Kerberos. Part 2 – Service Principal Names

    Apologies for the delay in posting Part 2 – I’ve been on holidays so it’s been a bit hard finding the time to write these posts. In this part we cover Service Principal Names (SPNs).

    In a previous post we covered the basics of Kerberos authentication. Everything is relatively straitforward, however I didn’t cover the one particular aspect. Namely, how does the Authorisation Service (AS) and remote Service share their shared secret?

    In an Active Directory domain, all computer and user objects have a password. This password is used as the basis of the shared secret between the AS and the remote service. If the remote service is running under an inbuilt principal such as LocalSystem or Network Service then the computer account’s password is used as the basis of the shared secret. If the remote service is running under a custom user account, then the user account’s password is used as the basis of the shared secret.

    So how does the AS know which user or computer account’s password should be used? When a user wishes to connect to a remote service, it tells the Domain Controller what Kerberos service it wishes to connect to. The AS searches through Active Directory to find a matching Service Principal Name (SPN). SPNs are attributes of user and computer objects in the directory. For example, for the computer w03-svr-sql we can see the following SPNs (using ADSIEdit):

    Service Principal Name (SPN)

    Service Principal Names (SPN)

    SPNs can be viewed, added and removed using a GUI tool like ADSIEdit, or you can do the same using a command line tool such as SetSPN (part of the Windows 2000 Resource Kit).

    Using SetSPN

    Generally, when installing a product such as SQL Server or IIS that supports Kerberos, SPNs are registered for you for the accounts that those products are configured to use. However you later change the user account that the services are running under, you may need to set a new SPN for that Kerberos authentication continues working.

    This method of determining the shared secret to be used between the AS and remote service raising a couple of gotchas which can break Kerberos Authentication:

    1) The missing SPN
    When installing IIS (and a lot of other common services) the installer will register a set of default SPNs in the Directory. However if you change the way that your service runs after installation, you may need to update the SPNs that are registered.

    For example, after installing IIS, SPNs for servername and servername.domain.tld are registered under the server’s computer account in Active Directory. These SPNs will allow Kerberos authentication to work when using the following built-in service principles: LocalSystem, Network Service or Local Service as the identity for your worker processes.

    However if you change the process identity of your web application pool, and assign its worker process a custom domain user acccount as a process identity, then you will need to create SPNs for servername and servername.domain.tld under this custom user account. This allows the KDC to encrypt the service ticket with the password of the user account rather than the computer account.

    2) The duplicate SPN
    In the event that an SPN for the same service is registered under multiple accounts in Active Directory (e.g. under a computer account and a user account), then the KDC will not know which password should be used to encrypt the service ticket, and Kerberos Authentication will fail.

    In the above scenario, once you change the identity of your web application pool, and add the new SPNs for servername and servername.domain.tld, you may need to remove the existing SPNs from under the computer account. Likewise, if you change the process identity from one user account, to another user account, you would most likely need to remove the SPNs from the first user account, and add them to the second user account.

    3) Load-balanced IIS solutions
    In this situation, the user’s request might be routed to either of the two (or more) nodes in your cluster. In this case, you can not run your web application pools under an inbuilt principal (such as Network Service), because the KDC can not know which computer account’s password should be used (it does not know which node in the cluster the request will be routed to). In this situation you must use a common domain user account as the process identity of your worker processes.

    4) Multiple web applications hosted at a single domain name
    Because SPNs are organised by name (either NetBIOS or fully qualified domain name), all web applications hosted at that domain name must be running in worker processes utilising the same, common, identity. This is so that the KDC can generate a service ticket using that identity, no matter what web application is being accessed at the FQDN. You can still run the web applications in separate web application pools, but each pool must be running under the same, common, identity.

    IIS and Kerberos. Part 3 – A simple scenario

    In Part 3 of this series we look at setting up Kerberos Authentication in the simplest possible scenario. If you missed Parts 1 (What is Kerberos and how does it work) and 2 (Service Principal Names) they may be worth reading first. In this scenario, we have a client, a DC and a single IIS server. As we progress through the series, we will progressively add more elements into the mix.

    In this very simplistic example a client wishes to authenticate to a website hosted on the webserver. The sequence of events is illustrated in the diagram:

    IIS and Kerberos - a simple scenario

    1) The client makes a HTTP Request
    2) The server denies the request with a 401 Authorization Required. It includes the WWW-Authenticate: Negotiate header and/or the WWW-Authenticate: Kerberos header indicating that it supports Kerberos authentication
    3) The client requests a Service Ticket from the KDC hosted on the Domain Controller
    4) The Domain Controller returns the Service Ticket
    5) The Client generates the Authenticator, and sends this plus the Service Ticket in a new HTTP request to the web server
    6) The webserver determines the identity of the client, checks the ACL on the resource and either permits or denies access to the resource.

    In order for this sequence of events to work the following need to be configured.

    The Browser
    For Internet Explorer to use Kerberos to authenticate to IIS the following must be configured correctly:

    1. Under Tools -> Internet Options -> Advanced the option “Enable Integrated Windows Authentication (Requires Restart)” must be checked. Whilst technically IWA encompasses both NTLm and Kerberos, IE will use NTLM only if this option is not checked whilst it can use both Kerberos or NTLM if this option is checked.
    2. The website you are connecting to must be located in the “Intranet” Security zone. You can see what zone IE thinks the website is in by looking at the icon in the bottom right-hand side of IE’s status bar. If the website is located in the “Internet” zone, IE will not even attempt Kerberos authentication. This is because, in most Internet scenarios, a connection with a domain controller can not be established. The simple rule is that any website that contains full stops (periods for Americans) such as an IP address or Fully Qualified Domain Name (FQDN) is in the Internet zone. If you are connecting to an IP address or FQDN then use IE’s settings or Group Policy to add this site to the Intranet security zone. For more information on how IE determines what zone the website is in please see KB 258063

    The Domain Controller
    For the Domain Controller to generate the appropriate tickets to give to the client an appropriate Service Principal Name (SPN) must be registered in Active Directory. When a Windows Server 2003 machine is added to a domain, a HOST SPN for both the NetBIOS name and the FQDN of the server is automatically added to Active Directory. If your website is accessible at http://servername or http://servername.domain.tld (tld = Top Level Domain, such .com or .local) and the web application pool is running as Network Service, Local Service or Local System, you do not need to change any SPNs.

    If the web application pool hosting the site is running under a custom account, the SPN HTTP/servername or HTTP/servername.domain.tld needs to be registered under that custom user account. If those HTTP SPNs exist under any other account, they need to be removed.

    And lastly, if the website is accessible at an arbitrary hostname that is unrelated to the actual server’s name (e.g. http://www.domain.tld) then a SPN needs to be registered for that hostname. If the web application pool hosting the website is running as Network Service, Local Service or LocalSystem, then the SPN needs to be registered under the server’s computer account. If the web app pool is running under a custom user account, then the SPN needs to be registered under that user account in Active Directory.

    SPNs can be added using a GUI-based tool such as ADSIEdit. Or can be added programmatically using an interface to AD (such as ADSI), or can be added using the SetSPN.exe command line tool (SetSPN is discussed in Part 2 of IIS and Kerberos listed earlier). To add an SPN using SetSPN for:

    1. a servername under a custom user account:
      setspn –A HTTP/servername Domain\Username
    2. an arbitrary hostname under a computer account:
      setspn –A HTTP/hostname.domain.tld Domain\MachineName
    3. an arbitrary hostname under a custom user account:
      setspn –A HTTP/hostname.domain.tld Domain\UserName

    The IIS Server
    There isn’t a lot to configure on the IIS Server. Firstly Integrated Windows Authentication (IWA) should be enabled for the website or application you are seeking to protect. By default this enabled both the Negotiate and NTLM Authentication Providers in the IIS metabase. If you have edited the metabase to remove the Negotiate provider, you will need to add it back in. The installation of some products (e.g. Sharepoint Portal Server 2001) removes the Negotiate provider – you may need to manually add it back in. See Microsoft KB Article 832769 for your options.

    Secondly, all web applications hosted at the DNS name in question need to be running in one or more web application pools that are all running under the same user account. It’s easiest if all the web applications at that DNS name are running in a single web app pool. However if you do need to split web applications into multiple pools, those pools need to be running under the same user account.

    Summary
    And that should be all that is required for your Internet Explorer browser to authenticate to IIS using Kerberos. To verify whether this is occuring, you can use the tools described in my previous post on determining whether the browser is using NTLM or Kerberos to authenticate to IIS.

    CÔNG TY TNHH NOVA SỐ – NOVA DIGITAL CO., LTD


    LỊCH SỬ HÌNH THÀNH.

    Cty TNHH NOVA DIGITAL được thành lập dưới sự tham gia cố vấn và đầu tư từ những chuyên gia công nghệ cao Microsoft, VMware, IBM, EMC với định hướng phát triển trở thành một trong những đơn vị hàng đầu về Sản xuất phần mềm Giải pháp, Tư vấn giải pháp, Dịch vụ Triển khai các Giải pháp phần mềm CNTT trong Quản lý Doanh nghiệp và Điều hành các hệ thống giải pháp Điện toán đám mây.

    Đội ngũ nhân sự có năng lực, kinh nghiệm trên 10 năm về triển khai và đào tạo công nghệ, sở hữu nhiều chứng chỉ Quốc tế quan trọng đảm bảo khả năng cạnh tranh trong việc phát triển dịch vụ Đào tạo và triển khai giải pháp CNTT tại Việt Nam và các nước ĐNÁ.

    LĨNH VỰC HOẠT ĐỘNG

    Công ty TNHH NOVA DIGITAL hoạt động trong lĩnh vực Sản xuất phẩm mềm Quản lý bằng CNTT, Dịch vụ triển khai và Đào tạo CNTT với thế mạnh nhiều năm kinh nghiệm:

    • Phát triển dịch vụ đào tạo chuyên ngành Công nghệ thông tin – Kinh tế và Viễn thông.
    • Đối tác Hợp tác cung cấp các giải pháp CNTT cho 3 Hiệp hội chuyên ngành:
      • Hiệp hội Chế biến và Xuất khẩu Thuỷ sản Việt Nam – VASEP (hơn 500 Doanh nghiệp thành viên trong các lĩnh vực XNK, Chế biến, Sản xuất, Ngân hàng, Thương mại Thuỷ sản).  website: http://www.vasep.com.vn/ 
      • Hiệp hội Gỗ và Lâm sản Việt Nam (hơn 300 Doanh nghiệp thành viên trong các lĩnh vực XNK, chế biến, sản xuất, Ngân hàng, Thương mại Gỗ – nội thất). website:  http://vietfores.org/
      • Hiệp hội Chế biến và xuất khẩu Chè Việt Nam – VITAS ( hơn 80 Doanh nghiệp thành viên trong các lĩnh vực XNK, chế biến, sản xuất, Ngân hàng, Thương mại Chè – ẩm thực Việt Nam).  Website: http://www.vitas.org.vn
    • Các giải pháp phần mềm tin học vào ứng dụng cho doanh nghiệp vừa và nhỏ như:
      • Office 365 Cloud.
      • Cung cấp các phần mềm bản quyền của Microsoft, VMware, Lạc Việt cho Doanh nghiệp Việt Nam.
      • Chứng thư số của Viettel ISP cho khai báo thuế Việt Nam.
      • Hệ thống SMS của Viettel Telecom cho Quản lý sản xuất – Kinh tế.
    • Cung cấp giải phải pháp phần mềm tin học ứng dụng trong trường học Phổ thông và Đại học.
      • Hệ thống SMS của Viettel Telecom cho Quản lý Trường Đại học.
      • Hệ thống SMS Học bạ cho Quản lý Trường Phổ thông.
    • Đối tác triển khai giải pháp duy nhất của Microsoft Live@edu tại Việt Nam.
      • Triển khai hệ thống Exchange Online, SharePoint Online, Forefront Protection for Exchange Online, Skydrive.
      • Tích hợp hệ thống ADSync với Windows Live ID và SSO.
      • Triển khai các giải pháp SSO giữa Moodle hoặc SharePoint On-premise với Outlook Live.
      • Dịch vụ Đào tạo Live@edu for Administrators và Giáo viên các Trường Phổ thông – Đại học.
    • Đối tác duy nhất triển khai nâng cấp Office365 Education của Microsoft tại Việt Nam.
      • Nâng cấp từ Microsoft Live@edu sang Office 365 cho 300 trường PTCS, 128 trường PTTH, 40 Trường CĐ- Trung học chuyên nghiệp, 37 Trường Đại học,  20 Viện và Sau Đại học tại 39 tỉnh thành Việt Nam.
      • Cung cấp phần mềm và triển khai các giải pháp tích hợp, khai thác Office 365 cho toàn bộ các Trường tại Việt Nam.
      • Dịch vụ đào tạo Office 365 gồm 3 môn chuẩn của Microsoft:
        • Course 70-321 Deploying Office 365.
        • Course 70-323 Administering Office 365 for SMB.
        • Course 74-324 End User Office365 training.
    • Đại lý chính thức AER và LAR của Microsoft cung cấp phần mềm giáo dục tại Việt Nam.
    • Đối tác đạo tạo University và Triển khai giải pháp Ảo hoá Chuyên nghiệp của VMware tại Việt Nam.
      • Đại lý sản phẩm phần mềm ảo hoá VMware.
      • Đối tác đào tạo uỷ quyền của VMware tại Việt Nam.
      • Đối tác triển khai Service Solution IT Professional of VMware.
    • Trung tâm thi chứng chỉ Công nghệ Thông tin Quốc tế Prometric, Pearson Vue.
    • Xây dựng trang web điện tử, xây dựng cổng thông tin Doanh nghiệp.

     

    CƠ CẤU TỔ CHỨC & NHÂN SỰ

    Để thực hiện các chức năng nhiệm vụ phát triển dịch vụ Đào tạo, định hướng kinh doanh, cung cấp các giải pháp ứng dụng CNTT, đảm bảo dịch vụ hỗ trợ khách hàng và duy trì hoạt động của Trung tâm một cách hiệu quả, NOVA Digital đã xây dựng một cơ cấu tổ chức một cách chặt chẽ, hợp lý bao gồm các phòng ban có mối quan hệ hỗ trợ và phối hợp đồng bộ tạo nên một sức mạnh tập thể. Đáp ứng và cung cấp các dịch vụ phục vụ khách hàng Doanh nghiệp một cách toàn diện, chu đáo.

    image

    CEO: Giám đốc điều hành

    CIO: Giám đốc kỹ thuật.

    CMO: Giám đốc quản lý đối tác.

    CFO: Trưởng quản lý tài chính kế toán.

    AM: Quản lý khách hàng.

    CCO: Trưởng quản lý chăm sóc khách hàng.

    CTO: Trưởng quản lý kỹ thuật và triển khai hỗ trợ kỹ thuật Khách hàng.

     

    NỀN TẢNG CÔNG NGHỆ – CHỨNG CHỈ NĂNG LỰC

    Chứng chỉ công nghệ Microsoft MCP:

              Chứng chỉ chuyên ngành cao cấp về hệ thống mạng (MCITP)

              Chứng chỉ chuyên gia CNTT về SharePoint 2010 (MCM).

              Chứng chỉ chuyên gia CNTT về Dynamic CRM.

              Chứng chỉ chuyên gia về Đào tạo CNTT của Microsoft (MCT)

    Partner Microsoft Live@edu

    image

    Đối tác duy nhất triển khai Microsoft Live@edu tại Việt Nam.

    Microsoft Licensing Sales Specialist LAR & AER

    Chứng chỉ cấp phép bán hàng chuyên khối Doanh nghiệp, chính phủ và Giáo dục.

     

    Microsoft Office Specialist

    Chứng chỉ chuyên ngành về hoạt động nghiệp vụ văn phòng

    Microsoft Learning Solution

    Ủy quyền của Microsoft về cung cấp các giải pháp cho Giáo dục và Đào tạo

    Microsoft SharePoint Platform

              Cung cấp giải pháp Cổng thông tin điện tử và Microsoft Learning Gateway theo nền tảng SharePoint.

              Gia công phần mềm, triển khai dịch vụ hỗ trợ kỹ thuật cho các Trường Quốc tế và Đại học như: Hanoi University of Pharmacy – http://www.hup.edu.vn , UNISHANOI: http://portal.unishanoi.org

    Microsoft Dynamic CRM

    Giải pháp triển khai hệ thống Chăm sóc khách hàng

    Microsoft Business Intelligence

              Giải pháp Doanh nghiệp thông minh chuyên cung cấp giải pháp BI 2008, BI 2012 trên nền Windows Server 2008 R2, Windows Server 2012 cho Hải Quan Việt Nam và Hiệp hội CBXN TS VASEP, Hiệp hội Chè VITAS.

    Đối tác của SourceCode

    image

    Chuyên triển khai giải pháp “Business Process Management Solution” cho Doanh nghiệp Viễn thông Viettel Telecom tại 64 tỉnh thành.

    Khảo thí thi chứng chỉ Quốc tế

    image

              Chuyên tổ chức thi chứng chỉ CNTT của Microsoft, IBM, WMware.


    SẢN PHẨM, GIẢI PHÁP & DỊCH VỤ

    1.      Chương trình Microsoft Partner Program

              Đối tác của Microsoft phát triển mạng lưới và đánh giá, xác thực năng lực đối tác tại Việt Nam.

              Phát triển các gói sản phẩm, giải pháp cho các doanh nghiệp, đối tác.

              Đại lý chính thức cung cấp các phần mềm có bản quyền tại Việt Nam.

    2.      Chương trình Microsoft LAR & AER (Microsoft Authorized Education Resller)

    Tư vấn, cung cấp và đào tạo khai thác các phần mềm có bản quyền của Microsoft cho các đơn vị là Trường Đại học, Cao đẳng, THPT…

    3.      Chương trình Live@edu và Office365 Cloud

    Đối tác độc quyền triển khai cung cấp gói dịch vụ Microsoft Cloud miễn phí cho khối Giáo dục tại Việt Nam, Lào, Campuchia bao gồm:

              Hệ thống Email trực tuyến.

              Hệ thống cổng thông tin giáo dục trực tuyến.

              Hệ thống hội thảo trực tuyến.

              Hệ thống Microsoft Office trực tuyến.

              Hệ thống Dynamic CRM trực tuyến.

              Dịch vụ hỗ trợ, tư vấn và triển khai kỹ thuật Microsoft Cloud.

    4.      Giải pháp phần mềm dựa trên nền tảng hạ tầng SharePoint và .Net Framework

              Cung cấp giải pháp cổng thông tin quản lý nội dung giáo trình, giáo án, trắc nghiệm cho khối giáo dục.

              Cung cấp giải pháp cổng thông tin quản lý nội dung giáo trình, giáo án, trắc nghiệm cho khối doanh nghiệp quản trị nhân sự.

    5.      Giải pháp dịch vụ gia tăng trên di động (SMS Mobile)

    Cung cấp giải pháp quản lý học sinh, sinh viên và phản hồi thông tin qua tổng đài nhắn tin thuê bao điện thoại di động.

    6.      Phòng thi chứng chỉ Quốc tế được khảo thí ủy quyền của Prometric và Pearson Vue

    Phòng thi đạt tiêu chuẩn Quốc tế được Prometric ủy quyền cho phép học viên thi và nhận các chứng chỉ chuyên ngành CNTT đạt chuẩn Quốc tế tại Việt Nam.

    7.      Giải pháp ảo hóa hệ thống VMware

    Đối tác độc quyền của VMware tại Việt Nam

              Tư vấn giải pháp.

              Triển khai hạ tầng.

              Đào tạo và chuyển giao công nghệ.

    8.      Giải pháp phát triển dịch vụ trực tuyến trên nền Microsoft Cloud computing

    Đối tác duy nhất tại Việt nam tư vấn, triển khai, đào tạo và chuyển giao công nghệ về các giải pháp trên nền Microsoft Cloud Apps.

    KHÁCH HÀNG TIÊU BIỂU

    Các thành viên xây dựng NOVA DIGITAL đều là những người có từ 10 – 16 năm kinh nghiệm triển khai trong các lĩnh vực:

    1.      Dầu khí: PVOL

    2.      Ngân hàng: Vietin Bank, VP Bank

    3.      Bảo hiểm: Prudential, Manulife

    4.      Vinamilk

    5.      Đào tạo: RMIT University, de Heus, HUP, HUBT, HCMUT, NEU, HLU, Nhất Nghệ, DNU, HUESTAR.

    6.      Hải Quan: Hải Quan Việt nam, FAO – FIIU – WCOO.

    7.      Viễn Thông: Viettel Telecom.

    8.      Truyền hình: VTC, Viettel Media, Mobiphone Media, PGM Senvang, HTC

     

    CÁC DỰ ÁN TIÊU BIỂU ĐÃ THỰC HIỆN

    Khách hàng Doanh nghiệp

    Thời gian

    Sản phẩm và dịch vụ cung cấp

    Viettel Telecom

    (64 tỉnh thành, 6000 người dùng).

    2007

    Giải pháp Quản lý Quy trình về Hợp đồng Mua Bán

    của  K2Workflow SourceCode trên nền SharePoint Office 2007 Server

    Microsoft

    2008

    Mô hình giải pháp SMS Mobile ứng dụng cho Nông thôn

    VASEP

    2011

    Cổng thông tin chuyên ngành Thủy sản

    http://www.vasep.com.vn

    VITAS

    2010

    Công thông tin nội bộ Hiệp hội Chè

    http://portal.vitas.org.vn

    Microsoft for Education

    Từ 2008 đến nay

    Chương trình Live@edu triển khai tại Việt Nam cho:

    – 300 trường PTCS

    – 128 trường PTTH

    – 40 Trường CĐ- Trung học chuyên nghiệp

    – 37 Trường Đại học

    – 20 Viện và Sau Đại học tại 39 tỉnh thành Việt Nam.

    – 15 Trường Quốc tế.

    VISC

    2012

    Trang học bạ trực tuyến Hocba.vn

    http://hocba.vn

    Viettel CA

    2010

    Cung cấp chữ ký số cho các ngành Thuế, Hải quan điện tử và các Doanh nghiệp thuê Hosting máy chủ.

    NAT&L

    2009

    Tư vấn và triển khai giải pháp Mobile SMS Gateway của Microsoft UPG tại nhà máy mía đường Nghệ An.

    Bộ Nông nghiệp (MART)

    2009

    Triển khai giải pháp thống kê giá nông nghiệp qua Mobile (Microsoft Project MIDAS)

    Khách hàng GIÁO DỤC

    Thời gian

    Sản phẩm và dịch vụ cung cấp

    Đại học Dược HN (Hanoi University of Pharmacy)

    11.000 người dùng

    2010

    Triển khai giải pháp hạ tầng Web hosting, Sharepoint portal, Learning Geatway, hội thảo trực tuyến bằng Microsoft Lync Online.

    Website: http://www.hup.edu.vn

    Kiểu dự án: Lai ghép điện toán đám mây

    Đại học Văn Lang

    25.000 người dùng

    2009

    Triển khai dịch vụ hạ tầng Outlook Live, Moodle tích hợp Windows Live ID.

    Website: http://www.vanlanguni.edu.vn/

    Kiểu dự án: Lai ghép điện toán đám mây

    Đại học Bách Khoa TP.HCM

    35.000 người dùng

    2009

    Triển khai dịch vụ hạ tầng Outlook Live, PSA tích hợp Windows Live ID.

    Website: http://www.hcmut.edu.vn/en

    Kiểu dự án: Cloud and On-Premise

    Đại học Tôn Đức Thắng

    45.000 người dùng

    2010

    Triển khai dịch vụ hạ tầng Outlook Live, PowerShell đồng bộ dữ liệu người dùng.

    Website: http://english.tdt.edu.vn/ 

    Kiểu dự án: Lai ghép điện toán đám mây

    Đại học Đà nẵng

    32.000 người dùng

    2009

    Triển khai dịch vụ hạ tầng Outlook Live, PowerShell đồng bộ dữ liệu người dùng.

    Triển khai Cổng thông tin Moodle Learning với Windows Live ID.

    Website: http://www.dnu.edu.vn

    Kiểu dự án: Lai ghép điện toán đám mây

    Đại Học Dân lập Thăng Long

    9000 người dùng

    2008

    Triển khai dịch vụ hạ tầng Outlook Live, PowerShell đồng bộ dữ liệu người dùng.

    Triển khai Cổng thông tin Joomla với Windows Live ID.

    Website: http://thanglong.edu.vn/

    Kiểu dự án: Lai ghép điện toán đám mây

    Đại học Đông Đô

    5000 người dùng

    2009

    Triển khai dịch vụ hạ tầng Outlook Live, PowerShell đồng bộ dữ liệu người dùng.

    Triển khai Cổng thông tin ASP.Net với Windows Live ID.

    Website: http://www.dongdo.edu.vn

    Kiểu dự án: Lai ghép điện toán đám mây

    Đại học Quản trị Kinh Doanh Công nghệ HUBT

    25.000 người dùng

    2010

    Triển khai dịch vụ hạ tầng Outlook Live, PowerShell đồng bộ dữ liệu người dùng.

    Triển khai Cổng thông tin Moodle Learning với Windows Live ID.

    Website: http://www.hubt.edu.vn

    Kiểu dự án: Lai ghép điện toán đám mây

    Khách hàng GIÁO DỤC QUỐC TẾ

    Thời gian

    Sản phẩm và dịch vụ cung cấp

    Australian International School – Vietnam

     

    1000 người dùng

    2012 đến nay

    Triển khai dịch vụ hạ tầng Outlook Live, PowerShell đồng bộ dữ liệu người dùng.

    Triển khai Cổng thông tin SharePoint 2010 với Windows Live ID và SSO.

    Website: http://www.aisvietnam.com

    Kiểu dự án: Lai ghép điện toán đám mây

    Kinder World Group

    2000 người dùng

    2010

    Triển khai dịch vụ hạ tầng Outlook Live, PowerShell đồng bộ dữ liệu người dùng.

    Triển khai Cổng thông tin Joomla với Windows Live ID và SSO.

    Website: http://kinderworld.net/

    Kiểu dự án: Lai ghép điện toán đám mây

    the International School Ho Chi Minh City (ISHCMC)

    3000 người dùng

    2011

    Triển khai dịch vụ hạ tầng Outlook Live, PowerShell đồng bộ dữ liệu người dùng.

    Triển khai Cổng thông tin Joomla với Windows Live ID và SSO.

    http://www.ishcmc.com/

    UnisHanoi

    1000 người dùng

    2012 đến nay

    Tư vấn giải pháp SharePoint, Exchange và triển khai Hạ dịch vụ quản lý hệ thống trọn gói

    http://portal.unishanoi.org

     

    ĐỐI TÁC CHIẾN LƯỢC CỦA NOVA DIGITAL

    Doanh nghiệp mạnh về cung cấp giải pháp, thiết bị, dịch vụ  và phần mềm CNTT

    image

    Microsoft Small Business Specialist

    Đối tác triển khai dịch vụ Office 365 cho Trường CĐ, ĐH và Doanh nghiệp

    Đối tác chuyên triển khai và đào tạo các giải pháp Cổng thông tin SharePoint, BizTalk, SQL, Lync và Office Online.

    image

    Solution Service IT Professional

    Đối tác chuyên triển khai giải pháp Ảo hoá vCenter & vCloud mạng Doanh nghiệp cho các Trường CĐ, ĐH và Doanh nghiệp.

    image

    Solution Service NAS Professional

    Đối tác chuyên triển khai giải pháp Lưu trữ mạng nội bộ và Điện toán đám mây NAS to LAN & vCloud cho các Trường CĐ, ĐH và Doanh nghiệp.

    image

     Service Provider SERVER & SAN Professional

    Đối tác chuyên triển khai giải pháp Máy chủ Server & SAN cho các Trường CĐ, ĐH và Doanh nghiệp.

     

    image

              Đối tác tư vấn và triển khai hệ thống phần mềm giải pháp dịch vụ khai báo Hải quan “E-Manifest Vietnam Customs”.

              Đối tác tư vấn và triển khai hệ thống Quản lý Nội dung số Truyền hình Viễn thông Viettel Media.

    image

              Đối tác tư vấn và triển khai sản phẩm phần mềm Quản lý tài chính Khách hàng Doanh nghiệp ERP.

    image

              Đối tác tư vấn và triển khai hệ thống Quản lý Nội dung số Truyền hình Tin tức VTC Media.

              Đối tác tư vấn và triển khai hạ tầng ảo hoá trong Đào tạo CNTT VTC Labs Management.

    image

              Đối tác tư vấn và triển khai hệ thống Quản lý dịch vụ Ảo hoá Điện toán đám mây vCloud CMC IDC HCMC.

     

    Doanh nghiệp tiên phong trong lĩnh vực Đào tạo CNTT

    image

    image

    1.      Viện Đào tạo Công nghệ và Quản trị Robusta

    2.      IPMAC.

    3.      IT Academic Thang Long.

    4.      NetPro IT Academic.

    5.      Trung tâm CNTT Đại học Kinh doanh và Công nghệ Hà nội.

    6.      Viện đào tạo CNTT & Viễn thông – Đại Học Mở Hà Nội.

    7.      Viện Đào tạo Công nghệ sau đại học – Đại Học Bách Khoa Hà nội.

    8.      Học viện CNTT – Kinh tế Quốc Dân.

    9.      Trường Cao đẳng Công nghiệp Huế.

    10.  Nhất Nghệ.

     

    Đối tác Hiệp hội Doanh nghiệp Thông tấn

    image

              14 năm Đối tác tư vấn và triển khai hỗ trợ nâng cao năng lực CNTT tại Hiệp hội Doanh nghiệp thủy sản Việt Nam (VASEP)

    image

              4 năm Đối tác tư vấn và triển khai xây dựng, đào tạo năng lực quản lý nghiệp vụ văn phòng tại Hiệp hội Chè Việt Nam (VITAS)

     

    image

              14 năm làm Đối tác tư vấn và hỗ trợ kỹ thuật  CNTT tại Doanh nghiệp sản xuất và chế biến đồ Gỗ nội thất trực thuộc Hội Gỗ Việt Nam

    ĐỊNH HƯỚNG PHÁT TRIỂN TRONG TƯƠNG LAI

    Chúng tôi cam kết

              Chất lượng dịch vụ là kim chỉ nam cho mọi hoạt động của chúng tôi do đó chúng tôi luôn tập trung để thỏa mãn yêu cầu của khách hàng với tinh thần phục vụ tận tụy và sự hiểu biết sâu sắc về nhu cầu đề ra.

              Cùng với đó chúng tôi không ngừng nâng cao năng lực công nghệ và cải tiến quy trình chất lượng nhằm cung cấp những sản phẩm và dịch vụ có chất lượng tốt nhất.

              Chân thành, chủ động trong việc xây dựng quan hệ đối tác để cùng phát triển.

              Đoàn kết nội bộ, nỗ lực phấn đấu vì một sự nghiệp Giáo dục tiến bộ.

              Tái đầu tư xã hội thông qua các hoạt động Giáo dục cộng đồng.

    Chiến lược phát triển

              Chúng tôi không ngừng đầu tư để đảm bảo luôn đi trước và đón đầu công nghệ tiên tiến dựa trên những đối tác chiến lược lâu năm.

              Không ngừng mở rộng quan hệ đối tác tạo cơ hội phát triển lớn mạnh.

              Xây dựng mạng lưới khách hàng sâu rộng và bền vững.

              Đẩy mạnh công tác đào tạo, chuyển giao công nghệ với các hãng đối tác.

              Xây dựng chiến lược nhân sự ổn định dựa trên triết lý nhân bản sâu sắc.

              Hướng tới mục tiêu trở một trong những đơn vị tiên phong về cung cấp dịch vụ đào tạo và giải pháp công nghệ tại khu vực Châu Á Thái Bình Dương.

     

    %d bloggers like this: