If you want the app to authenticate directly against AD, then you generally either do something LDAP-based with forms auth or you use a built in feature of IIS like basic or integrated. Note that the latter depends on the server being joined to the domain in order for IIS to be able to authenticate them.
If the server is domain joined and you still want to show your own login UI but don't want to do LDAP, you can use p/invoke to call the LogonUser API. This is similar to what IIS does on your behalf when you use Basic auth.
My expectation is that if the machine is a domain member, then the ports required for LDAP would be open to the domain controllers so you should be able to do LDAP-based authentication in that case. If the machine is not domain-joined and also has no LDAP access through firewall, then I don't see how the admins would expect you to be able to authenticate users against the directory.
My suggestion in cases where you may have users from multiple identity realms (you mentioned external users in SQL as well) would be to look at a federation-based approach. There is great info here:
http://claimsid.codeplex.com/
The federation-based approach is also very flexible in that the web server may be deployed in such as way that it has no direct connectivity to the directory at all but can still authenticate users externally due to the federation trust.
As Rich already said, LDAP is built into Windows so there is no chance it isn't "installed". Windows LDAP and ADSI come with the OS and all versions of .NET have shipped with at least one LDAP stack. The question is whether or not you can use it. You haven't really provided enough information about the network deployment of the server in consideration to get a good answer to that question. :)