Wow...this is a fun topic. Remember folks, SOX is all about accountability and controls. There are no "rules" that are hard and fast. When I do SOX audits what I suggest to one company may be completely different than another company. The thing to always remember, validate and document. If you have a valid business reason for something, say full system access of all systems for one person (which, by the way, is VERY common), document it.
What you need to be careful of from an auditing perspective is not having the business reasons to back up any processes you aren't seeming in compliance with. For instance, if someone tells me "I need production access because I promote and do package builds in production"...that isn't going to fly, you do not need access for this. Now if the answer is "because I'm a IT island of one in the company", now you have a valid point. Now we can sit down and "document" how you will "control" your access when in production, and "document" on an ongoing basis your access in that environment.
Another thing I always tell folks when they start getting queasy about locking CNC out of production, is that as long as there is a separate account, and it's use is documented (that is a log or journal entry as to who used the account, when, what for), you've satisfied SOX requirements.
I find it humorous that the biggest gripe about a SOX audit is usually the access issues, when I see the biggest issues are doing things that many organizations haven't: Have a documented and tested DR plan, have a documented and implemented change control strategy, unifying software accross the enterprise (and documentation of licensing), and the level of documenting that will be needed to be performed on an ongoing basis.
Long and short of it, if you've got a valid reason, and you document it, there shouldn't be anything that can't be 'worked out' from a SOX perspective.