Windows Server 2003 accounts - Disable user login via a machine but allow login for email
We have a windows AD that has some user mailboxes for some general email accounts that other physical human endusers users need access to from non extended mapi clients. They endusers have to login as that user mailbox to get/send email as that account due to the lack of Outlook based clients we have on the OS's and we don't want to forward email to the enduser account. I was wondering if anyone knows if there is a way to easily disable these email mailbox accounts from being able to actually log on to a physical machine terminal on a computer on the domain but still be able to login for actual email account access?
Coolie Sheppard
Instead of creating an actual domain user with a mailbox, create a contact and mail enable him. This way, that contact cannot log on to the domain.
ASKER
Does a mail contact have an actual mailbox associated with it? I didn't think they did.
You can mail enable the contact with an email account from your domain.
you can disable the user account itself, and give other users full access to it by right click the mailbox from exchange console and choose manage full access and add the required users
it can be opened later on from any users' OWA under open another mailbox in the right top
Another way to do this would be disable the user account, but if you want the mailbox to remain open when the account is disabled disabled you could grant SELF associated mailbox access.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
you asked mainly for disabled users, but you can prevent them from logon locally from group policy give it the Deny Logon Locally permission and link that to the domain once and for all.
The GPO-setting for restricting logon locally is included in what I posted earlier, so why isn't that post included in answer?
My opinion is as said that http:#21654282 should be included in solution because the accepted comment mentions the policy setting that I already had posted.
The other part of my comment shall work as it's the way I've configured our monitoring user accounts to not be able to logon to any other machine in the domain than the servers hosting the services they monitor (POP3 on Exchange servers for example).
The other part of my comment shall work as it's the way I've configured our monitoring user accounts to not be able to logon to any other machine in the domain than the servers hosting the services they monitor (POP3 on Exchange servers for example).
I think the only correct answers to the question were henjoh09's and my own. That said, I was merely follow up, and only added a picture for demonstration.
LogOnTo method should as said work, but user nead to be allowed to log on to computer which primary requests authentication and not DC. If authentication is requested when connecting to POP3-service and user don't have a kerberos ticket from client authentication, user neads to be allowed to logon to the server hosting POP3-service.
Disable user as suggested in other post will not work as it prevents user from authenticate with any service in domain.
User rights assignment "deny logon locally" will prevent listed users from logging on locally (console) on computers affected by GPO with policy setting. GPO nead to be linked anywhere in domain-structure so computer account can "see" GPO, either at root level or a OU-level closer to computer account. Both posts about the user rights assignment is with that said correct, but what I primary objected against is that the post that first included the setting and in my eyes was more complete wasn't included as part of solution (even if solution was to link GPO to domain level, I think it should had been better with a split to include both posts).
Disable user as suggested in other post will not work as it prevents user from authenticate with any service in domain.
User rights assignment "deny logon locally" will prevent listed users from logging on locally (console) on computers affected by GPO with policy setting. GPO nead to be linked anywhere in domain-structure so computer account can "see" GPO, either at root level or a OU-level closer to computer account. Both posts about the user rights assignment is with that said correct, but what I primary objected against is that the post that first included the setting and in my eyes was more complete wasn't included as part of solution (even if solution was to link GPO to domain level, I think it should had been better with a split to include both posts).