Wednesday, January 30, 2013

CONTACT,AT MICROSOFT.RE.CA. CERTS!!

Links to Other Resources

For all credential provider information and questions, send e-mail to the Shell Credential Provider alias: credprov@microsoft.com.

http://msdn.microsoft.com/en-us/library/bb756900.aspx


Application Compatibility: Microsoft Graphical Identification and Authentication (GINA)

2 out of 4 rated this helpful - Rate this topicMicrosoft Graphical Identification and Authentication (GINA)

Feature Impact

High (frequency: low)

Brief Description

Prior to Windows Vista® and Windows Server® 2008, for logons to a third-party server or with a third-party device, ISVs had to replace the Graphical Identification and Authentication (GINA) dynamic-link library in Windows XP®. Such applications also had to replace the existing UI and implement smart-card and remote-desktop features on Windows XP.Note:If an application did not function this way in Windows XP, this information does not apply.Windows Vista and Windows Server 2008 introduce a new authentication model where LogonUI and WinLogon communicate directly with each other. This model provides a simplicity, scalability, and flexibility that did not exist with GINA. Unlike with the GINA module, ISVs no longer need to replace the UI for the logon screen, thus relieving the ISV of the burden of re-authoring the user interface for the user. An ISV can author a credential provider, which is a module that plugs into the LogonUI, to describe the UI and to gather the credential and pass it on to WinLogon. Credential providers are completely transparent to WinLogon.Credential providers are also additive, meaning that users can install multiple credential providers and pick the one that they want to use. Credential providers can be user-selected, event-driven, or both. Multiple credential providers can coexist on Windows Vista and Windows Server 2008 and are not only for third parties. In fact, Windows will ship two credential providers in the box: a credential provider for user name and password and a credential provider for smart card.Additionally, credential providers can be reused within CredUI. That is, the same object that describes and collects credential information on LogonUI can be used to gather the very same credentials in CredUI scenarios.The GINA functionality from Windows XP and Windows Server 2003 has been deprecated and removed from Windows Vista and Windows Server 2008. The GINA modules of applications will not function and must be re-authored using the new authentication model for Windows Vista and Windows Server 2008.

Manifestation

The user will not be able to successfully install custom logon applications.The user will not be able to log on using custom logon applications (using the Windows XP technology) in Windows Vista and Windows Server 2008. These applications might include biometric devices, custom logon UI, or virtual private network (VPN) solutions for remote users with custom logon UI.

Remedies

Leverage new capability:The applications or components that use the GINA technology must be re-authored to use the new logon authentication model for Windows Vista and Windows Server 2008.

Links to Other Resources

For all credential provider information and questions, send e-mail to the Shell Credential Provider alias: credprov@microsoft.com.See Also


Application Compatibility: Read Only Domain Controllers (RODC)

This topic has not yet been rated - Rate this topicRead-Only Domain Controllers (RODC)

Feature Impact

Moderate

Brief Description

A Read-Only Domain Controller (RODC) is a new type of domain controller under the Windows Server 2008 operating system. With an RODC, organizations can easily deploy a domain controller in locations where physical security cannot be guaranteed. An RODC hosts a read-only replica of the database in Active Directory® Domain Services (AD DS) for a given domain.Before the release of Windows Server 2008, if users had to authenticate with a domain controller over a wide area network (WAN), there was no real alternative. In many cases, this solution was not efficient. Branch offices often cannot provide adequate physical security that is required for a writable domain controller. Furthermore, branch offices often have poor network bandwidth when connected to a hub site. This limitation can increase the amount of time required to log on; it can also hamper access to network resources.Beginning with Windows Server 2008, an organization can deploy an RODC to address these problems. As a result, users in this situation can benefit from:Improved security.Faster logon times.More efficient access to resources on the network.

Manifestation

Any application that writes to the Active Directory is potentially impacted by RODCs and might see compatibility issues involving failed writes or failed reads of newly written data.

Remedies

Applications that write data might locate a domain controller using methods that do not differentiate between writable and read-only domain controllers.There are two methods that applications typically use to request the nearest domain controller:Serverless binding, as recommended in Binding to Active Directory Domain ServicesDomain controller Locator callsIn Windows Server 2008, a domain controller Locator call can return any domain controller, including a domain controller running Windows 2000 Server or Windows Server 2003 or a writable or read-only domain controller running Windows Server 2008.Problems can occur if an application needs to write to directory objects and it gets an RODC from calling a serverless bind. In that case, the write operations are referred to a writable domain controller running Windows Server 2008 at the hub site. Depending on the WAN connection to the hub site at that time, the application can fail to connect to the hub and can report errors. The application must also correctly handle these referrals. Even if the write operation succeeds, any subsequent reading of the data that was just written might fail because of inherent latency that is required to replicate this data back to the RODC.Applications that must run on a domain controller should be aware of RODCs. These applications must determine if the domain controller is writable or if it is an RODC. Checking the registry or using OSVERSIONINFOEX, as discussed in OSVERSIONINFOEX Structure, does not distinguish an RODC from a writable domain controller. An RODC still advertises itself as a domain controller.To making this determination, check the supportedCapabilities attribute on the rootDSE class. For more information, see Serverless Binding and RootDSE. The presence of object identifier value 1.2.840.113556.1.4.1920 indicates that the specified domain controller is an RODC.You can also use the DsRoleGetPrimaryDomainInformation function to determine if the domain controller is an RODC. A new flag has been added to the DSROLE_PRIMARY_DOMAIN_INFO_BASIC structure.

Links to Other Resources

Application Compatibility with RODCsThe Future of Active Directory (February 22, 2006) chatThe Future of Windows: Directory Services in Windows Server 2008See Also
http://msdn.microsoft.com/en-us/library/bb757005.aspx

No comments:

Post a Comment