I assume you're asking which server you should run your Active Directory services on?
Ideally it would be on its OWN server (even if it's virtualised), but if you have to share it, then I would be putting it on any server that is not directly accessed by the public.
So, what this means is: Not the Web server, and not the App server. Which leaves the DB server, but that's also a bad place to put it, because of the stress that most DB servers are under.
I'm going to make some broad assumptions here based on your phrasing.
It really depends on your usage. Are you just doing this for authentication? If so, then reconsider your implementation. There are other solutions for centralized authentication that don't require licensing and have smaller footprints (OpenLDAP comes to mind).
Definitely not the web tier if you mean front line by web tier. Again, going back to usage, if by database tier you mean actually using the Active Directory schema for information retrieval, OpenLDAP is going to be far more efficient, less resource intensive and really at this point, why not just use a proper database?
Domain Controllers make excellent application servers actually, but I wouldn't recommend them for an application used by a very large site. Do you want to run Sharepoint on them internally? Go ahead. Do you want to run your production web site that gets 3,000 hits per minute? Don't (unless you have the hardware, and even then you have security issues to worry about).
Will this be linked between your Intranet customers and real (paying) customers? If so, why do you really need to use shared authentication? A proper implementation isolates the outside world from your employees. If you want to make a stand alone domain for the purposes of 'ease of administration', then consider what happens to your application when your domain goes down and it can't authenticate to Active Directory. Do you really want to explain that to your boss?
This question is impossible to answer, because you are (in essence) mixing metaphors. The "tier" model is about distributing functions in an application, and has no relevance to the discussion about how to architect an Active Directory (aka AD) implementation. So, in your scenario (separate hardware for AD), the actual answer is NONE. The separate AD domain controller will not be in any of the "tiers".
AD is more complicated than it looks. There is more to it than running setup. Active Directory requires at least one "Domain Controller" (aka "DC"), which is a server running the "Active Directory services". It is strongly advised that there be more than one DC in an AD implementation, so that the ability to login isn't lost if the one DC fails. Other servers in an Active Directory are known as "member servers". Additionally, there are some special services (aka "FSMO roles") which can only be activated on a single DC per domain or location. It is also strongly advised that Exchange, SQL Server, or any high-traffic application not be run on a DC, for performance and redundancy reasons. It is also generally recommended that a DC not be exposed directly to the internet, because there are lots of services running and ports open on a DC. Further, AD requires that it be the primary DNS for the domain.
That said, if AD is just going to authenticate users for a web application, there is no real problem having it on one of the existing servers. I would choose the "app" tier server, because it is better not to have it on the web-facing server for security reasons, and better not to have it on the DB server for performance reasons.
However, as noted by others, AD is not the best choice for authentication alone and is almost certainly overkill, particularly for you since you don't know how to use it. If the number of users is going to be small and not change much, you can use local Windows authentication which is built into IIS.
I assume you're asking which server you should run your Active Directory services on?
Ideally it would be on its OWN server (even if it's virtualised), but if you have to share it, then I would be putting it on any server that is not directly accessed by the public.
So, what this means is: Not the Web server, and not the App server. Which leaves the DB server, but that's also a bad place to put it, because of the stress that most DB servers are under.
I'm going to make some broad assumptions here based on your phrasing.
It really depends on your usage. Are you just doing this for authentication? If so, then reconsider your implementation. There are other solutions for centralized authentication that don't require licensing and have smaller footprints (OpenLDAP comes to mind).
Definitely not the web tier if you mean front line by web tier. Again, going back to usage, if by database tier you mean actually using the Active Directory schema for information retrieval, OpenLDAP is going to be far more efficient, less resource intensive and really at this point, why not just use a proper database?
Domain Controllers make excellent application servers actually, but I wouldn't recommend them for an application used by a very large site. Do you want to run Sharepoint on them internally? Go ahead. Do you want to run your production web site that gets 3,000 hits per minute? Don't (unless you have the hardware, and even then you have security issues to worry about).
Will this be linked between your Intranet customers and real (paying) customers? If so, why do you really need to use shared authentication? A proper implementation isolates the outside world from your employees. If you want to make a stand alone domain for the purposes of 'ease of administration', then consider what happens to your application when your domain goes down and it can't authenticate to Active Directory. Do you really want to explain that to your boss?
This question is impossible to answer, because you are (in essence) mixing metaphors. The "tier" model is about distributing functions in an application, and has no relevance to the discussion about how to architect an Active Directory (aka AD) implementation. So, in your scenario (separate hardware for AD), the actual answer is NONE. The separate AD domain controller will not be in any of the "tiers".
AD is more complicated than it looks. There is more to it than running setup. Active Directory requires at least one "Domain Controller" (aka "DC"), which is a server running the "Active Directory services". It is strongly advised that there be more than one DC in an AD implementation, so that the ability to login isn't lost if the one DC fails. Other servers in an Active Directory are known as "member servers". Additionally, there are some special services (aka "FSMO roles") which can only be activated on a single DC per domain or location. It is also strongly advised that Exchange, SQL Server, or any high-traffic application not be run on a DC, for performance and redundancy reasons. It is also generally recommended that a DC not be exposed directly to the internet, because there are lots of services running and ports open on a DC. Further, AD requires that it be the primary DNS for the domain.
That said, if AD is just going to authenticate users for a web application, there is no real problem having it on one of the existing servers. I would choose the "app" tier server, because it is better not to have it on the web-facing server for security reasons, and better not to have it on the DB server for performance reasons.
However, as noted by others, AD is not the best choice for authentication alone and is almost certainly overkill, particularly for you since you don't know how to use it. If the number of users is going to be small and not change much, you can use local Windows authentication which is built into IIS.