Every user has a unique SUID in SQL Server - dont complicate your life -remove the original user & re-add the new user, then re-do all the security as required.
Be careful too - an NT login ( or even a SQL login ) is mapped to a unique username in each database. If your original NT username owned objects in a database, then you wont be able to remove the username from the database until all object ownerships have been transferred to sa or dbo. But this could cause problems with any application you are running, so if this is an issue, you may need to carefully work through it.
(By the way - its a big no-no to have a user owning objects - all objects in a database should be owned by dbo or sa and then you dont have a problem.)
Part of the reasons for the questions I'm asking are to flesh out the actual problem, hence the comments about dbo & sa owning all objects.
In most situations, I would always have dbo or sa owning all objects. Good security setup in the database ( if professionally configured ) will always be secure. I dont tolerate people that leave sa blank nor should anyone else - good for a pink slip in my book.
In some cases e.g. an application during its operation or installation may create objects in the database, that would be valid case for non-dbo/sa ownership ( but still not a great state of affairs - especially if its an internet exposed app).
If there is a bonafide reason for it, I'm open to suggestion. But in most cases, not good practice.
I agree with SQLGuy. users owning objects will lead to more problems than solutions. Consider if you have two users that create tables with the same name. Now there is no telling what results either user would get from queries that reference either table (unless they fully qualify the names in those queries/stored procs). Then there are all the problems around the fact that a user can now drop a table in your database. Or create 200 indexes on the table. It is too much of a potential problem.
I am surprised you get the same issue with the new user.
Some suggestions as we work this out:
(1) Lets test whether you have a DNS probem - see if you can ping the domain controller by name and TCPIP address from the SQL box.
(2) If you can ping the domain controller by name, open a dos box & type: ipconfig /all and look for the WINS & DNS server entries. If you dont have any that will probably be the reason. Speak to your networking guys about that.
(3) If you can ping the domain controller & you have correct WINS & DNS entries under ipconfig /all try going to your NT security and try & add the user under NT security to the local Users group on the box. At this point if you cant do this, you have a general networking issue & will need to fix it before we can progress the problem.