Access internally is DAO. The recordsets for forms/reports are DAO NOT ADO.
If you are doing this because you want to use unbound forms, you are using the wrong front end software. Access is a Rapid Application Development (RAD) tool. It's best feature is bound forms. They are what make Access Access and if you don't use them, you are taking all the dead weight and tossing away the good stuff.
If you follow good client/server design methods, you will be fine using linked tables and bound forms.
Sometimes a question about "how to do XXXX" leads to the answer, "DON'T do XXXX
because there's a better way."
As Pat says, this is one of those times. ADO is a great tool for some tasks, but it's not the end goal, so to speak, for all tasks. Bound forms are the shiny part of Access, moving all of the nitty gritty out of your way so you can concentrate on other, more productive things.
That said, I have used ADO to update certain fields in a remote SQL Server database in a handful of situations, almost always, though, those have been cases where I did not want to bind a form to the table but did need to pass certain pieces of data back to that table.
On the other hand, I also think that part of the growth of an Access developer can be exploring all sorts of tools, e.g. learning about ADO and where and when it can be a useful tool. As just noted, the two cases that I can recall using ADO were both where we were aggregating data locally following the import of raw data. That aggregated data needed to be store permanently in a remote SQL Server database for use in a website. Not the raw data, but the aggregated data. Pushing that data via ADO was probably the best solution since it did not require linking to the remote tables.
I'll go see if I can find some of that code--it's been more than 5 years since I retired so it's not handy at the moment. In the meantime, someone will probably have an ADO example already....