Forefront TMG 2010 uses server publishing rules to map requests for non-Web servers located in a Forefront TMG 2010 network from clients located in other networks. Clients can be external clients located on the Internet or internal clients located on a different internal network. When the network on which the published server is located has a NAT relationship with the network from which client requests are located, server publishing works as follows:The IP address published by the server-published rule belongs to Forefront TMG. Clients make a request for the published resource to the client-facing adapter on the Forefront TMG server and not directly to the internal server.By default, the client source address sent to the published server is that of client. You can change this setting to specify that the source address sent to the published server is that of the Forefront TMG server.When the network on which the published server is located has a route relationship with the network from which client requests are located, server publishing works as follows:Forefront TMG listens for requests on the IP address of the published server.Clients make a request to the IP address of the internal server.Server publishing rules display the following characteristics:Server publishing can be used to publish most TCP and UDP protocols.The published server should be configured as a SecureNAT client with a default gateway pointing to Forefront TMG 2010.You cannot authenticate user requests for server publishing rules.You can use IP address control to specify who can access published resources.A server publishing rule can only publish a single server and protocolIn some circumstances you may want to consider using server publishing rules instead of access rules for internal client requests. For example, if you want to allow internal clients to access a non-Web server located in a perimeter network. For a comparison of using server publishing rules or access rules, see the Microsoft TechNet article About network relationships and firewall policy (http://technet.microsoft.com/en-us/library/cc995201.aspx).
For non-HTTP requests, Forefront TMG 2010 checks network rules, and then checks publishing rules to determine if requests are allowed.Overriding default ports Server publishing configures Forefront TMG 2010 to listen on a specific port and forward requests to a published server. You can configure the following port properties:Specify the port on which should listen for requests for request. If you publish on a port other than the default port, Forefront TMG 2010 receives client requests for the published service on the nonstandard port, and then forwards requests to the designated port on the published server. For example, a server publishing rule may specify that client requests for FTP services connect through port 22 on the Forefront TMG 2010 computer before being redirected to the default port 21 on the published server.
When using server publishing rules, Forefront TMG 2010 forwards the traffic as it does for access rules, but it uses application filters directly. For example, the Single Mail Transfer Protocol (SMTP) filter is not used for SMTP traffic handled by an access rule, but it is used with traffic handled by a server publishing rule.In server publishing rules, the client in the destination network makes a connection to the Forefront TMG IP address on which the publishing rule is listening for requests. When Forefront TMG 2010 forwards the traffic to the published server, it replaces the Forefront TMG IP address with the IP address of the internal server that it is publishing, but it does not modify the source IP address. Note that in a NAT relationship, server publishing rules can only access the network specified as the destination network. In addition, because server publishing across networks with NAT leaves the source IP address intact when forwarding traffic to the published server, the published server must use the Forefront TMG 2010 computer as the last hop in the routing structure to the destination network. If this is not possible, configure server publishing rules to use the setting Requests appear to come from the Forefront TMG computer. This causes Forefront TMG 2010 to perform full NAT on the traffic handled by the rule.
Forefront TMG Web publishing makes Web content securely available to groups of users or to all users who send requests to your organization from the Internet. The Web content requested is typically stored on Web servers in the Internal network or in a perimeter network (also known as a screened subnet or a demilitarized zone (DMZ)).With Web publishing rules, you can allow or deny requests based on defined access policies. You can restrict access to specified users, computers, or networks, require user authentication, and inspect the traffic. Content caching enables Forefront TMG 2010 to cache Web content and to respond to user requests from the cache without forwarding the requests downstream to the published Web server. This type of content caching is called reverse caching. Web publishing rules have many features that determine how client Web requests are passed to the published Web servers, including the following:Mapping requests to specific internal paths to limit the portions of your Web servers that can be accessed.Delegation of user credentials for authenticating Forefront TMG to the Web server after authentication by Forefront TMG 2010, without requiring users to supply their credentials for a second time.Link translation for replacing internal host names and paths in Web content with public names and external paths.Secure Sockets Layer (SSL) bridging, which enables Forefront TMG to inspect incoming HTTPS requests and then forward them to the Web server over an encrypted SSL channel.Load balancing of client requests among the Web servers in a server farm, with maintenance of client affinity for increased availability and improved performance.
When you create a Web publishing rule, you specify a Web listener to be used when applying the rule. The Web listener properties determine:Which Internet Protocol (IP) addresses and ports on the specified networks will listen for Web requests. Which authentication method will be usedwhen authentication is required. Number of client connections that are allowed. The Web listener is used to:Indicate the IP address and port to which a client makes a connection. Enable TMG 2010 to pre-authenticate the connection. Web listeners can be used by more than one Web publishing rule.
The Web listener network, or networks, that you select depends on which network clients will use to connect to the published Web server. For example, if the Web site you are publishing allows client requests from the Internet (the external network), you should select the External network for the Web listener. By selecting the External network, you are selecting the IP addresses on the Forefront TMG 2010 computer that are associated with the external network adapter. If you do not limit the IP addresses, all IP addresses associated with the selected network adapter will be included in the listener configuration.Web listeners are used by a Web publishing rule. The rule specifies source network objects in addition to specifying a Web listener. The network objects specified as sources in the Web publishing rule must include the networks selected for the Web listener. Publishing multiple SSL Web sites on selected IP addresses You can specify that a Web listener will listen on one or more specific IP addresses. When you do so for an HTTPS Web listener, you can choose to assign a single certificate to all of the IP addresses, or to assign a different certificate to each IP address. Assigning a different certificate to each IP address enables you to publish several sites over HTTPS by using the same Web listener, without using a wildcard certificate. For example, you can publish mail.contoso.com by using a certificate with that name on one IP address, and team.contoso.com by using a certificate with that name on a different IP address.Alternatively, you can publish multiple Secure Sockets Layer (SSL) Web sites by using a single Web listener and a wildcard certificate. For instructions for implementing this scenario, see the Microsoft TechNet article Using wildcard certificates (http://technet.microsoft.com/en-us/library/cc441561.aspx).By using the same listener for several sites, you can take advantage of the Forefront TMG 2010 single sign-on (SS0) feature, which requires a common Web listener for all of the SSO sites.Authentication You can create Web publishing rules that allow or deny access to a set of computers or to a group of users. If the rule applies specifically to users, Forefront TMG 2010 checks the incoming Web request properties to determine how the user will be authenticated. For example, a Web publishing rule might allow access only to specific users. Forefront TMG 2010 will authenticate the user requesting the object, to determine whether the Web publishing rule allows the requesting user access. The user must authenticate, using one of the authentication methods specified for the incoming Web requests.Forefront TMG provides a secure, encrypted logon environment for browsers that support Microsoft Windows NT® Challenge/Response authentication, and for other browsers that use Basic authentication. Authentication methods can be set for all IP addresses on the server, or separately for each IP address.Single sign-on (SSO) enables your users to move safely from one application to another, without having to reauthenticate. SSO is configured on the Single Sign On Settings page of the New Web Listener Wizard, and is available for HTML forms-based authentication.For more information about authentication in Forefront TMG, see the Microsoft TechNet article Overview of client authentication (http://technet.microsoft.com/en-us/library/cc995161.aspx).Limiting concurrent connections By limiting the number of client connections allowed simultaneously to the Forefront TMG 2010 computer, you can prevent attacks that may overwhelm the system's resources. This is particularly useful when publishing servers.
Single sign-on (SSO) enables users to authenticate once to Microsoft Forefront Threat Management Gateway and then, without reauthenticating, access all of the Web sites with the same domain suffix that Forefront TMG 2010 publishes on a specific Web listener. Web sites can include Microsoft® Outlook® Web Access and Microsoft® SharePoint® Server sites, as well as standard Internet Information Services (IIS) Web sites.A typical example of SSO is a user who logs on to Outlook Web Access by providing credentials on a form. In one of the e-mail messages that the user receives, there is a link to a document that is stored on a SharePoint server. The user clicks the link, and the document opens without an additional request for authentication. This example relies on the use of persistent cookies.Security notes As long as a user's browser process is still running, that user is logged on. For example, a user logs on to Outlook Web Access. From the Microsoft Internet Explorer menu, the user opens a new browser window and then navigates to another site. Closing the Outlook Web Access window does not end the session, and the user is still logged on.When enabling SSO, be sure to provide a restrictive SSO domain. Providing an inclusive domain, such as .co.uk, allows the Web browser to send the Forefront TMG SSO cookie to any Web site in that domain, creating a possible security risk.In a scenario where you create a Web listener that uses forms-based authentication with RSA SecurID validation and you enable Collect additional delegation credentials in the form, Forefront TMG 2010 does not verify whether a user enters the same or a different name for the additional credentials.Note: There is no support for SSO between different Web listeners. SSO is supported for published Web sites whose host names have the same DNS suffix after the first dot. For example, you can configure SSO when publishing mail.fabrikam.com and team.fabrikam.com by specifying .fabrikam.com as the SSO domain. However, you cannot configure SSO for mail.fabrikam.com and mail.contoso.com. In addition, a DNS suffix specified as an SSO domain must consist of at least two segments separated by an embedded dot. For example, .fabrikam.com and .portal.fabrikam.com are valid SSO domains, but .com is not a valid SSO domain.
Web pages returned from a Web server published by a Forefront TMG 2010 Web publishing rule may include links containing internal names of computers or Web sites and internal paths to Web content. Because external clients cannot resolve these internal names, these links are broken unless the internal names are replaced with the public names of published Web sites. Forefront TMG 2010 includes a built-in Web filter named Link Translation Filter, which uses mappings to translate internal names in links on Web pages to publicly resolvable names. Each mapping translates an internal URL (or part of a URL) to a public equivalent. For example, a mapping can translate the internal URL http://team to the public URL https://www.team.contoso.com for external users. Link translation mappings are stored in tables called link translation dictionaries.When link translation is enabled for a Web publishing rule, a default link translation dictionary is automatically created for each public name of the rule that does not contain a wildcard character (*).Forefront TMG 2010 includes link translation support for all published Web content, including support for Web publishing rules that publish servers running Microsoft Exchange Server and Microsoft Office SharePoint Server. Link translation is not applied to rules that publish FTP servers over HTTP.Types of mappings When link translation is enabled for a Web publishing rule, links in content sent from the published Web site to a client are translated according to the following mappings, which are stored in the effective link translation dictionary for the rule:Implicit mappings of the rule – These mappings are added automatically and map the internal name (or IP address) of the server published by the Web publishing rule to the public name (or IP address) of the Web site, or if there are multiple public names, to one of its public names. Local mappings – The user creates these mappings for the rule, and they map a string containing an internal host name to a string containing a publicly resolvable host name. The string to be translated must contain at least four characters. A local mapping can override an implicit mapping of the rule. Local mappings are not added automatically to the effective link translation dictionaries of other rules.Implicit mappings of other rules – These mappings are automatically added to the effective link translation dictionary of every Web publishing rule that is defined and enabled and has link translation enabled on the Forefront TMG computer. These mappings are derived from the implicit mappings defined in each Web publishing rule on the Forefront TMG computer. Global mappings – The user creates these mappings for the Forefront TMG computer, and they apply to all Web publishing rules in the Forefront TMG 2010 computer. These mappings override conflicting implicit mappings of other rules. Adding local mappingsLocal mappings can be defined for a Web publishing rule on the Locally Defined Mappings page. To open this page, on the Properties page for the rule, on the Link Translations tab, click Configure. To create a local mapping, you need to specify a string containing the internal name (or IP address) of a Web site or host and a string containing the publicly resolvable name to which the internal name should be translated. The translated name is typically the public name that can be accessed by external clients, such as the fully qualified domain name (FQDN) or IP address of the Forefront TMG 2010 computer. Note that in the same rule, you cannot define more than one local mapping for a string to be translated. Adding global mappingsGlobal mappings can be defined on the Global Mappings tab of the Link Translation properties. To create a global mapping, you need to specify an internal URL and the public URL to which the internal URL should be translated. The internal URL typically contains the name (or IP address) of an internal Web site or host. The translated URL is typically the public name that can be accessed by external clients, such as the FQDN or IP address of the Forefront TMG 2010 computer. The URLs specified in user-defined global mappings must begin with a valid protocol (http:// or https://).
Virtual private network (VPN) technology enables cost-effective, secure, remote access to private networks. With a VPN, you can extend your private network across a shared or public network, such as the Internet, in a manner that emulates a point-to-point private link. By using the Forefront TMG computer as the VPN server, you benefit by protecting your corporate network from malicious VPN connections. Because the VPN server is integrated into the firewall functionality, VPN users are subject to the Forefront TMG firewall policy.About Forefront TMG VPNsForefront TMG 2010 supports two types of VPNs: Remote access VPN – Provides roaming users with secure remote access to the internal networkSite-to-site VPN – Enables quick connectivity between sites, for example between a main office and its branch offices. Note: All VPN connections to Forefront TMG are logged to the Firewall log, so that you can monitor them. Forefront TMG implements Windows Server VPN technology. For a description, see What Is VPN? (http://go.microsoft.com/fwlink/?LinkId=160092). When reading this content, keep in mind the functional differences between Windows Server 2003 and later versions of Windows as documented in What's New in Routing and Remote Access in Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkId=160094).
Network Access Protection (NAP) consists of several components and architecture models that work in conjunction to provide security for the network. The infrastructure of NAP supports the different servers required to validate, remediate and provide health certificates. The enforcement methods used by NAP (802.1x, DHCP, VPN, NPS RADIUS and IPSec) provide flexibility in determining the appropriate method for securing client access to your network.
NAP Support in TMG 2010 allows you to define levels of network access based on a client’s identity, the groups to which the client belongs, and the degree to which the client complies with corporate governance policy. If a client is not compliant, NAP provides a mechanism for automatically bringing the client into compliance (a process known as remediation), and then dynamically increases its level of network access.
Remote Access Quarantine Service (RQS) and Remote Access Quarantine Client (RQC).
Used in combination with Forefront TMG 2010, NAP can enforce a health policy when client computers attempt to connect to the network by using a VPN connection. VPN enforcement provides strong limited network access for all computers accessing the network through a VPN connection. Configuring NAP on the NPS includes the following tasks:Installing the NPS roleSetting Forefront TMG as a RADIUS clientCreating system health validators and policiesCreating network policiesCreating connection request policiesEnabling the NAP service on NAP-capable client computers
Remote Access Connectivity OptionsForefront TMG 2010 Connectivity Example Method Goal Usage Scenario Non-HTTP server Connectivity to specific Access to internal e-mail Publishing internal non-HTTP servers (SMTP) server Web server publishing Connectivity to internal Access to Outlook Web Web servers application Virtual Private Network Full connectivity to the Access for employees corporate network connecting from home or at a customer site
Forefront TMG 2010 vs. Forefront™ Unified AccessGateway (UAG)Product Positioning Forefront TMG 2010 Enables users to safely and productively use the Internet without worrying about malware and other threats Forefront UAG Comprehensive, secure remote access to corporate resources Forefront UAG is the preferred solution for providing remote access Forefront TMG 2010 still provides support for remote access features, but not the recommended solution
Non-HTTP Server Publishing Allows map requests for non-Web servers in one of the TMG 2010 networks Clients can be either on the Internet or on a different internal network Can be used to publish most TCP and UDP protocol Behavior depends on whether non-Web server is behind a NAT relationship or not If behind NAT, clients will then connect to an IP address belonging to Forefront TMG If behind a route relationship, TMG 2010 listens for requests on the IP address of the non-Web server The published server should be configured as a SecureNAT client with a default gateway pointing to TMG 2010
Sample Server Publishing ScenarioDNS Server Publishing 192.168.0.100 DG: 192.168.0.3 ` DNS Server 220.127.116.11 10.0.0.3 192.168.0.3 192.168.0.254 TMG 1. DNS request 18.104.22.168 > 10.0.0.3 2. Check rule match 192.168.0.101 DG: 192.168.0.254 FTP Server
Sample Server Publishing ScenarioDNS Server Publishing1. DNS request 22.214.171.124 > 10.0.0.32. Check rule match 192.168.0.100 DG: 192.168.0.33. Rule matched `4. Check rule action DNS Server 126.96.36.199. Action is allow6. Evaluate filters 10.0.0.3 192.168.0.2547. Request OK 192.168.0.3 TMG8. Forward request 188.8.131.52 > 192.168.0.1009. Server response 192.168.0.101 DG: 192.168.0.254 192.168.0.100 > 184.108.40.206 FTP Server
Sample Server Publishing ScenarioFTP Server Publishing1. FTP request 192.168.0.100 DG: 192.168.0.3 220.127.116.11 > 10.0.0.3 `2. Check rule match DNS Server3. Rule matched 18.104.22.168. Check rule action 10.0.0.35. Action is allow 192.168.0.3 192.168.0.254 TMG6. Evaluate filters7. Request OK8. Forward request to FTP 192.168.0.101 DG: 192.168.0.254 192.168.0.3 > 192.168.0.101 FTP Server9. FTP server response 192.168.0.101 > 192.168.0.310. TMG response 10.0.0.3 > 22.214.171.124
Server Publishing Wizards Available from Firewall Policy Tasks Publish common non-Web protocols Publish mail (SMTP) servers
Non-HTTP Server Publishing Things to consider when planning Server Publishing No authentication support Access restriction by network elements only Networks, subnets, or IP addresses No support in single adapter configuration Client source IP address preserved Behavior can be changed using rule setting Application Layer Filter and NIS signature coverage SMTP, POP3, DNS, etc. 18
Web Publishing Provides secure access to Web content to users from the Internet Web content may be either on internal networks on in a DMZ Supports HTTP and HTTPS connections Forefront TMG 2010 Web Publishing features: Mapping requests to specific internal paths in specific servers Allows authentication and authorization of users at TMG level Allow delegation of user credentials after TMG authentication Caching of the published content (reverse caching) Inspection of incoming HTTPS requests using SSL bridging Load balancing of client requests among Web servers in a server farm
Accessing Web Resources OWA RPC/HTTP(S) HTTPS ActiveSync Exchange Server HTTPS HTTP ` HTTP HTTPS Web Internet Server HTTP SharePoint Server Forefront TMG 2010 can publish multiple internal Web servers, using multiple external IP addresses and protocols
Configuring1. Define web listeners IP addresses and ports that will listen for Web requests Authentication method used (client to TMG 2010) Server certificates and SSL options Number of client connections allowed2. Create other rule elements Source addresses Web farms User sets Schedules3. Run appropriate wizard 22
Configuring Web ListenersAssigning Certificate to Web Listener Showing Invalid Certificates Private Key not Installed Certificate Missing
Securing SSL Traffic SSL Bridging: 1. Client on Internet encrypts communications 2. TMG 2010 decrypts and inspects traffic 3. TMG 2010 sends allowed traffic to published server, re-encrypting it if required
Authentication Process1. Client credentials received2&3. Credentials validated4. Credentials delegated to internal server5. Server send response6. Response forwarded to client
Configuring Web ListenersClient Authentication Methods Authentication Providers: Credential Types: Credential Types: AuthenticationPassword Basic Username and Password Username and Username and Passcode Active Directory Username and Passcode Providers: LDAP Username, Password and Active Directory only RADIUS Passcode Fallback to: Providers: Authentication Providers: Digest Authentication BasicActiveDirectory only Active Directory Active Directory Digest server Integrated LDAP server LDAP Integrated Directory only RADIUS Active RADIUS RADIUS OTP RADIUS OTP RSA SecurID RSA SecurID Fallback to Basic Fallback to Basic Password Management Password Management
Authentication DelegationAuthentication Methods None – client cannot authenticate directly None – client can authenticate directly Basic authentication NTLM authentication Negotiate Kerberos/NTLM Kerberos Constrained Delegation SPN required for Kerberos Forefront TMG 2010 needs to be in the same domain as the published server
Single Sign OnSample Scenario – Two Published Web Sites requiring AuthN With Single Signon Without Single Signon: 1. User Prompted for authentication 2. User Clicks Link to SharePoint 3. User NOT Prompted for authentication Prompted for authentication again Exchange.Company.Com FBA ` SharePoint.Company.Com 30
Web Publishing Wizards Publish Web sites Publish SharePoint sites Publish Exchange Web client access Outlook® Web Access Outlook® Anywhere Exchange ActiveSync® Outlook® Mobile Access Microsoft® Exchange Server® 2003
Web Farms Distributes requests evenly among available Web servers Detect offline servers and implement consistent failover Allow the draining, removal, and addition of servers without disrupting current connections Methods for monitoring connectivity include HTTP GET, PING request, or TCP connection to a given port Supports IP or cookie-based affinity
Forefront TMG Virtual Private Networking (VPN) TMG 2010 supports two types of VPNs: Remote Access VPN Site-to-site VPN TMG 2010 implements Windows Server® 2008 VPN technology Implements support for Secure Socket Tunneling Protocol (SSTP) Implements support for Network Access Protection (NAP)
Secure Socket Tunneling Protocol (SSTP) New SSL-based VPN protocol HTTP with SSL session (TCP 443) between VPN clients and servers to exchange encapsulated IPv4 or IPv6 packets Support for unauthenticated Web proxies Support for Network Access Protection (NAP) Client support in Windows Vista® SP1 No plans to backport SSTP to previous versions
Network Access Protection (NAP)Windows Policy Validation and Enforcement Platform Policy Determines whether the computers are compliant with the company’s Validation security policy. Compliant computers are deemed healthy. Network Restricts network access to computers based on their health. Restriction Provides necessary updates to allow the computer to get healthy. Remediation Once healthy, the network restrictions are removed. Ongoing Changes to the company’s security policy or to the computers’ health Compliance may dynamically result in network restrictions.
NAP Support in Forefront TMG 2010 Enforces compliance and provides remediation for clients connecting remotely through Remote Access VPN Supports all VPN protocols, including SSTP Different solution than the Remote Access Quarantine Services (RQS) supported in ISA Server 2006 NAP validates health status of the remote client at connection time VPN network access limitation is done through IP packet filters applied to the VPN connection Access limited to resources on the restricted network
NAP with Forefront TMG Walkthrough Restricted Network Corporate Network Remediation Servers System Health Servers Unhealthy SHA performs remediation against remediation servers Ongoing policy updates to Network Here is the fix you need. Policy ServerVPN QEC passes SoH VPN QEC queries NAPAgent collects Responses back to new SoH and for SOHs NAPAgent passes NAPAgent to VPN QEC PEAP messages EAP VPN Session Request PEAP messages Can I pleaseHere is my SOH the network? have access to EAP - Response/Identity Here is my SOH EAP - Request/Identify RADIUS Access-Accept PEAPEAP - Request/Identify PEAP Message Message EAP – Request/Start – Send SOH State: – Request/Start – Send SOH EAP Quarantine State: Full Access Forefront TMG According to policy, the client is Client SOH Responses SOH Responses 2010 not up to date. Quarantine client. up to date. Restrict client to – no filters Grant access 10.10.10.0/24 Network Policy Server
NAP Components Platform Components Enforcement Components Health Components System Health Agents (SHA) = Declare = health status, coordinates between SHA and QEC. Quarantine Agent (QA) Clients (QEC) health (patch state, virus signature, system configuration, Quarantine Enforcement= Reports client Negotiate access with network access device(s); etc.). VPN, 1X, IPSec QECs. DHCP, System Health Validators= Restricts networknetworkto madebased on what SHV certifies. Network Access Devices = Provide client’s access access by health agents. Quarantine Server (QS) (SHV) = Certify declarations healthy endpoints. System Registration Authority = Issues certificates to clients that componentschecks. client. Health Health Servers = Define health requirements for system pass health on the Remediation Servers = Install necessary patches, configurations, applications. Bring clients to healthy state. Remediation Servers System Health Servers Updates Health policy Client Health Network Network Statements Access Requests Policy SHA<n> Server Health Result Quarantine SHV<n> Agent QEC QEC Quarantine Server Network Access Device 1 2 (Forefront TMG 2010)
Comparing NAP to RQS/RQC Remote Access Quarantine Service (RQS) and Remote Access Quarantine Client (RQC) Supports all versions of Windows® Requires configuration of scripts for policy evaluation and remediation Requires the use of Connection Manager Supports only remote access (VPN or dial up) connections Network Access Protection (NAP) Supports Microsoft Windows XP® Service Pack 3 or newer operating systems Requires System Health Agents (SHAs) for policy evaluation and remediation Supports any kind of network connection, with no requirements for Connection Manager usage Both methods are supported by Forefront TMG 2010
Configuring Forefront TMG with NAP1. Install Windows Server® 2008 or Windows Server® 2008 R2 Network Policy Server (NPS) role Preferably in a separate server from Forefront TMG 20102. Configure Forefront TMG 2010 as a RADIUS client3. Configure remote access policies at NPS server Configure System Health Validators (SHVs) and health policies Create network policies Create connection request policies Define remediation servers4. Configure NAP clients Enable NAP service and EAP quarantine agent Configure SHAs