Solved

Postmaster reading everyone's emails in NW 6.0?

Posted on 2006-06-14
52
1,333 Views
Last Modified: 2013-11-12
I am a network administrator recently placed over a network where another "collegue" is the email postmaster, and is very shady and sneaky. Our mailserver is NW 6.0. Everyone is suspecting that their mail has been re-routed by this individual for sometime and I am in the position to try and investigate these matters. I have admin rights in console one, though I have almost no groupwise experience. Is there a simple way to determine if any host relay or mail routing is taking place from the inside of this network? Emails that are critical of this man seem to never "get" delivered, from anywhere in the network. I am not in a good place, and I just need a little help. Thank you.
0
Comment
Question by:tekguy77
  • 21
  • 10
  • 9
  • +1
52 Comments
 
LVL 34

Accepted Solution

by:
PsiCop earned 168 total points
ID: 16903087
By "NW 6.0" I assume you mean "NetWare v6.0". NetWare is a NOS (Network Operating System), not an E-Mail system. So, I'm guessing by your choice of TA that you have GroupWise, altho I don't know what version of that. I note in passing that NetWare v6.0 has been EOLed, and the replacement product is Open Enterprise Server (OES), which gives you a choice of a Linux or a NetWare kernel. The latest version of GroupWise is v7.0.

Assuming you have a modern GroupWise version (e.g. v6.0 or later), there's no configuration option by which the Postmaster could have had every E-Mail copied to his/her mailbox, at least not in the *stock* GroupWise environment. There are a number of ways, most involving other software, to achieve a similar effect.

For example, the anti-SPAM/anti-virus tool GWAVA has a "Surveilance" feature that makes copies of E-Mail sent/received by either selected users or entire GroupWise systems. Placing a mail gateway between the GWIA and the outside world, one with appropriate functionality, could also be used. The Postmaster could even lower the Post Office Security settings on the GroupWise POA and access mailboxes directly, or establish themselves as a Proxy for all mailboxes - these methods don't require additional software, but are fairly obvious.

However, there's no single setting to accomplish mailbox intrusion on a widespread scale.
0
 

Author Comment

by:tekguy77
ID: 16903481
I am not certain of the groupwise version we are running with our NW v6.0 server OS. All our users have to use the web interface on our website to access their mailbox. Is there an easy way to check our mail gateway for the security compromises that you are able to see, and have mentioned might be in place, even if there is 3rd party software involved?
0
 
LVL 34

Expert Comment

by:PsiCop
ID: 16903826
If the users are primarily accessing their mailbox via WebAccess, then that pretty much eliminates the former Postmaster having lowered POA Security - WebAccess requires that all accounts have passwords.

If the Postmaster had made themselves able to Proxy into everyone's mailbox, then the account they were using will show in the list of Proxy IDs permitted. I don't recall how to look this up in WebAccess.

If a 3rd party software was used, then how you would go about looking for it depends a great deal on what it was. GWAVA runs on the NetWare server, on the same server as the MTA component of GroupWise. Look for GWAVA screens on that server. If the GWIA was fronted by a relay host, then GWIA would probably be configured to relay all outbound E-mail to that host. Check the GWIA Properties. If a tool like Guinevere was used, then there will be a value in the THIRD Directory Property of the GWIA configuration.

Hard to advise you exactly where to look when I don't even know the VERSION of GroupWise. If the previous sysadmin was so incompetent as to leave no documentation of the environment, then that's going to be very difficult for a remote person to try to help you create. It's really something only you can do on-site. Consider engaging local consulting services to help you out - someone with a current CNE certification, and not a VAR who will want to find problems (whether they exist or not) so they can sell you something.
0
 

Author Comment

by:tekguy77
ID: 16904234
All users do have passwords, both  Novell login, and groupwise email, but the current postmaster insists on "managing" them and he "tells" users what their password "will" be, (many users do not understand how to change it). (I see this as a clear security issue all to itself).Besides the obvious logging in from home,(or at work) to user's accounts via the webaccess, using the password he gave them; that I can help users by showing them how to change their passwords, and I feel that remedy is forthcoming. Because he and I are the only console one admin users, and he has told me that "all mail issues are mine", I have not ventured into the groupwise area in our tree. It would be easy for him to have settings set that I would have no reason to ever investigate (until now). Our groupwise version is definetly 6.0. I am not at work and cannot get to my console one to check things out, but I will tommorrow. Is there a setting that would grant access to groupwise on the Novell login password only? The previous sysadmin was fired for incompetence and theft. Things are not smooth.
0
 
LVL 34

Expert Comment

by:PsiCop
ID: 16904843
Ah. If the Postmaster is assigning passwords, then yes, he can login to any mailbox on the system, either thru WebAccess or the native client (or IMAP, or whatever). No special settings needed.

Because GroupWise was designed as a multi-platform system (and is not tied to a single platform, like Exchange is), it maintains its own authentication database. You *can* configure the POA to accept the eDirectory login state as an authentication credential, but you cannot *force* it to ignore the GroupWise credentials in favor of eDirectory.

The solution is for users to set their own passwords.
0
 
LVL 34

Expert Comment

by:PsiCop
ID: 16904863
Also, since WebAccess has no eDirectory authentication state, it has no choice but to rely on the GroupWise password. The only way around that is to implement some sort of web portal that creates an authentication state that WebAccess can subsequently use.
0
 
LVL 19

Expert Comment

by:billmercer
ID: 16905155
>All users do have passwords, both  Novell login, and groupwise email, but the current postmaster insists on "managing"
>them and he "tells" users what their password "will" be
Well, in theory this is not necessarily a security problem. If there are control mechanisms in place to prevent abuse, such as auditing of all admin activity, requiring two people to make changes, etc, it could be ok. But in your case it definitely sounds like that's NOT the case.

There are basically two approaches to testing the theory that he's snooping in people's email - the technical approach and the social/psychological approach.
Technically, you could use brute force, change HIS password, log in as him, and see what he's got access to. Not subtle, but effective. Or you could be more subtle, by checking
A more subtle approach is to look for traces of his snooping in the POA logs. If you have access to the server, you can try monitoring activity on the POA, where you can see who logs into groupwise and what address they're using. If you see lots of people checking their email from HIS ip address, you know what's up. Ditto for web access.

If you don't have access to the POA, or logging is not enabled, you can still identify

For example, if he logs in or proxies in and reads someone else's email, then resets the messages to unread using the "Read Later" option, this won't change the timestamp that shows when the message was originally opened. You can look for cases where an email you sent someone shows as having been opened at a time that you know the user wasn't reading their email.

If he's sneaky enough, he can avoid this by simply not reading emails until they have already been opened by the end user.

If you're worried about such direct action, the other approach is the "social engineering" method. Plant an email that creates a reaction from him which you can monitor. For example, if you have a web site, send an email with a link to an image stored on your server that you know is not linked to anywhere else. Send the message to someone you suspect he's snooping on. Then simply watch your server logs. If you see someone hit that page, bingo. To improve odds of him visiting the link, hint at the possibility that  scantily clad women are involved, that's about 90% likely to work.

This approach isn't gonna hold up in court, but it can give you the ammunition you need to do something more aggressive.

>many users do not understand how to change it
If the users do have the ability to change their own passwords, then simply have them chage them. If he complains, or changes it back, you got him, because he wouldn't notice the password change if he wasn't snooping. But it's possible he has set it so users can't change their own passwords.

>Is there a setting that would grant access to groupwise on the Novell login password only?
Yes, this is possible. There's an option called Single Signon in the security options for GroupWise. If this is on, you just have to be logged into NDS and you can access your GroupWise account without entering a password.

>Things are not smooth.
I once inadvertently stumbled into a user's personal life when I spotted herr logging into WebAccess at an unusual time. I asked her about it, and it turns out she hadn't. It was her jealous boyfriend reading her email from home. That got REAL ugly.
0
 

Author Comment

by:tekguy77
ID: 16905594
If everyone changes their groupwise passwords through 'options' in their mailbox from the webaccess, will that override and safeguard all the users email accounts? Am I getting this straight, that groupwise passwords trump the default Novell (assigned from on high) login passwords as far as email accounts are concerned? Once that groupwise password is set, the Novell login password becomes unuseable for email access? Also, if I can get the word out for all the users to change their email passwords, will these be safe from hacking? Are they cached on the web or mail server, or on the individual's work station? What measures would it take to "re-harvest" all the groupwise "new" passwords and put us right back where we are now?
0
 
LVL 34

Expert Comment

by:PsiCop
ID: 16906828
Yes, if everyone changes their mailbox passwords, then the only way the Postmaster can get into the average user's mailbox is by changing the user's password - a practice which would rapidly become evident.

I'm not sure why you expect WebAccess to honor the eDirectory account password. There is no authentication state (to eDirectory) for WebAccess to honor. So WebAccess has no choice but to rely on the GroupWise Mailbox password. Remember, GroupWise is multi-platform, and designed to work in many environments.

The ONLY way for the eDirectory credentials to work for accessing the mailbox is when there is an authentication state to be queried. In specific, this works with the GroupWise "fat" client running on a platform with a Novell Client (e.g. Novell Client for Linux, Novell Client 32 for Windows, Novell Client for Mac) where the user has authenticated to eDirectory. In such an environment, the GroupWise client can query the Novell Client for the eDirectory authentication state and present that to the GroupWise server.

This feature requires that the POA be set to High Security with eDirectory Authentication. And, of course, there needs to be an eDirectory back-end.

The GroupWise mailbox password is stored in the user's database in the GroupWise Post Office directory structure. All GroupWise databases are encrypted, so the only way to "hack" the password is to either brute-force it, or change it. There's no easy way to "harvest" the passwords.
0
 
LVL 19

Expert Comment

by:billmercer
ID: 16906995
>Am I getting this straight, that groupwise passwords trump the default Novell (assigned from on high) login passwords as far as
> email accounts are concerned?

Not necessarily. It depends on whether the single signon option and edirectory authentication options are enabled. If disabled, then yes, the GroupWise password is mandatory. But if the edir authentication option is on, then a user logged into edirectory can read their email without using the GroupWise password. And that means anyone who knows their edirectory password can read their email. The key here is that it's a configurable option. The groupwise administrator (that guy you don't trust) gets to decide how it will work. With WebAccess, there's no NDS authentication, so the only password needed is the GroupWise password.

Check a user's security options. If the "allow single signon" option is grayed out, that means it's been configred at the post office level, and users aren't allowed to change it. Changing this will require you to venture into that Groupwise part of ConsoleOne.

>Also, if I can get the word out for all the users to change their email passwords, will these be safe from hacking?
They'll be just as safe from hacking as anything else on your network, which is to say, not very. As long as you have a network administrator you don't trust, nothing is safe. Period.

>Are they cached on the web or mail server
No.
>, or on the individual's work station?
Maybe. There's a client password caching option in the GroupWise client, and if the user is using WebAccess, and uses their browser's auto-login feature, their password may be stored in their browser configuration. With FireFox, this is easy to handle, sinmply delete that password entry. With IE, you have to clear all your saved passwords, an option buried somewhere in the Internet Options puzzle box.

>What measures would it take to "re-harvest" all the groupwise "new" passwords and put us right back where we are now?
Digging around on user's workstations, sniffing traffic on the network, or even forcing a keylogger to run in their login script, all are fairly easy for someone with admin access. One critical point about WebAccess: If you aren't using SSL, your email isn't secure. You don't need a fancy certificate from Verislime for this, you can roll your own cert, it's for encryption not identification.

Important questions for you:
How confident are you that this guy is dirty? Do you have corroborating evidence, or just general suspicions?
Make sure you're right before lowering the boom. If the last guy in YOUR role was an incompetent crook, it's possible this other guy has adopted these gestapo tactics more as a self-defense mechanism than out of malevolent intentions. (Even if it's not true, it could sound good to a jury in a wrongful dismissal suit.)
Make sure you document everything you do carefully, and make sure you have the approval of higher-ups for all your actions.

0
 
LVL 19

Expert Comment

by:billmercer
ID: 16907487
I have to disagree with PsiCop on a couple of points.
>Yes, if everyone changes their mailbox passwords, then the only way the Postmaster can get into the average user's
>mailbox is by changing the user's password - a practice which would rapidly become evident.

Not true if the users don't also change their edirectory passwords at the same time. As long as this guy knows their edir passwords, he doesn't need their GroupWise passwords, because he can use the edirectory authentication option of the GroupWise client. It doesn't matter if the users only use webaccess, you have to assume HE can use the GW client. So you gotta change both passwords.

>There's no easy way to "harvest" the passwords.
I don't agree, but maybe it's a matter of definition. You can't harvest passwords FROM GROUPWISE, but you can sure get 'em other ways. Keyloggers are pretty darn easy in my opinion.
A few things you may want to do right away, assuming you have the authority:
 - In ConsoleOne, highlight your post office, right click and choose Client Options, make sure the options for password caching, edir authentication, and single signon are all UNCHECKED.
 - Check your password restrictions to be sure reusing old passwords is turned off, and require a minimum of an 8 character password.
 - Make sure your Webaccess server is ONLY available over SSL. IIRC, 6.0 defaulted to no SSL when installed, which basically means you're wide open.  
 - Expire all edir passwords, and force users to create new ones on login.
 - Send email to everyone instructing them how to change their GroupWise password.
 - If you think this guy may be going byebye, make sure you get good backups ASAP.
 - Check your directory for suspicious or insecure accounts. Here's a freebie that helps with this...
  http://www.novell.com/coolsolutions/tools/14090.html



0
 
LVL 34

Expert Comment

by:PsiCop
ID: 16907601
billmercer,

I don't see where the Asker stated that the Postmaster knows the user's eDirectory passwords. While what you say is correct, it assumes something I don't think the Asker has stated.

And yes, my comments are framed from within GroupWise. The harvesting methods you enumerate are completely legitimate, but outside the scope of the Question.
0
 
LVL 19

Expert Comment

by:billmercer
ID: 16907738
>I don't see where the Asker stated that the Postmaster knows the user's eDirectory passwords.

I got that impression from this statement...
 "All users do have passwords, both Novell login, and groupwise email, but the current postmaster insists on "managing" them..."
If the postmaster dude doesn't have edir passwords, then the situation is definitely less bleak. But I'd still be worried.

>The harvesting methods you enumerate are completely legitimate, but outside the scope of the Question.
Oh poo, you're starting to sound like ShineOn... ;)

Seriously though, if someone has admin rights, there's pretty much nothing they can't compromise if they're ambitious enough. I guess my point is that GroupWise can't be considered secure unless the network it runs on is secure.
0
 
LVL 34

Expert Comment

by:PsiCop
ID: 16907853
"you're starting to sound like ShineOn"

Them's fightin' words! :-)
0
 

Author Comment

by:tekguy77
ID: 16908836
Thanks for all this input, I will gingerly try and probe the settings you have mentioned in console one and start looking at the files on our mail server too.You guys have said quite a mouthful, and I am trying to "get up to speed" with this issue at the fastest pace I can assimulate, please indulge my inexperience with the groupwise world and all it's components. I have to be very diplomatic in this dance as I am dealing with a rogue individual that may very well lose his job, and he is not too stable or self-secure.
   What is involved in detecting if a keylogger is running with your login as a script? Can running scripts be locked for all the users, or is it an option for each client to check at will on the Novell login prompt ? (I know I can at least check the option on my login). keylogging is not the same action as hacking email letters, though it seems that it is sure a component of it. I really want to get to the bottom of the actual email access issue ASAP. At any rate, I have alot of homework now to do before I can offer more questions, thanks again for your sage counsel. I hope that you will hang with me as this drama unfolds, as it may get ugly.
0
 
LVL 34

Expert Comment

by:PsiCop
ID: 16911043
There are so many ways to run a keylogger. Frankly, I wouldn't use a login script to do it - I'd just use the login script to deploy it, and then remove the installation script from the login script once the keylogger was deployed. Or, if your organization uses ZENworks, I'd deploy it that way. Or, if this individual is as "rogue" as you suggest, they may have gone around to staff computers at night (assuming they have 24x7 access). In short, finding spyware like keyloggers is a non-trivial task. And if a hardware keylogger is in use, then you'd have to examine every PC individually.
0
 
LVL 19

Expert Comment

by:billmercer
ID: 16911090
> What is involved in detecting if a keylogger is running with your login as a script?

Login scripts are run when users first log into the network, and for the most part they usually consist of useful things like mapping network volumes to drive letters, updating software,  and displaying informational messages on the screen. However they can be used to launch programs automatically, sort of like putting things in the Startup folder of your start menu.

In ConsoleOne,  right-click on a user or container, and look for the Login Script tab. You'll see a text box. It may be blank, or it might contain commands. Look for any lines that refer to executable or installer files, including .exe, .bat, etc. If you find one, investigate the program itself to see if it looks legitimate. (Google is very helpful here.) There are many legitimate reasons to put an executable in a login script, so don't assume anything you find is malware.

There's a login script for each individual user, and there's also one for each container. To be thorough, you'll need to look at them all, but I'd start with the .O and .OU containers.  

You can also get utilities that can detect the presence of keylogger programs running on a computer. Some antivirus software will detect keyloggers, but many won't because there are "legitimate" reasons for having them.

>Can running scripts be locked for all the users, or is it an option for each client to check at will on the Novell login prompt ?

It's possible to disable running login scripts on login, but of course, it's also possible for an administrator to lock this setting.


0
 
LVL 19

Expert Comment

by:billmercer
ID: 16911136
>And if a hardware keylogger is in use, then you'd have to examine every PC individually.
Yeah, unfortunately, it's physically impossible to detect a hardware keylogger with software. But, pragmatically speaking, this is less likely to be in place for everyone, for the simple reason that he would need to purchase a large number of these devices, and that gets expensive. If there's a particular person who you suspect this guy has a special interest in spying on, you may want to look at the back of their machine where the keyboard plugs in.


0
 

Author Comment

by:tekguy77
ID: 16916825
I went to console one, and in security settings under the client in the post office, all three items were checked. Single sign-on, NDS authentication, and the first one, I think is about caching or something. It did not make me feel too good. If I am understanding this right, by issuing passwords for "your Novell login" to all the users, and telling no one about the groupwise password setting option in webaccess, in effect, as postmaster, he can use the "dictated, and compelled" password he gave as HIS access into the mail (from his home) via the web access interface to all our users email! The users simply do not know about a separate groupwise password to be set in webaccess. If you guys give me a reasonable course of action to secure these accounts, I will deploy it user by user if I have to. (We have about 150 users).
   I also noticed that though I have full admin rights in console one, I was not assigned as a trustee to the POA.(He assigned himself only, before I came aboard). I almost added myself to be a trustee, but was afraid it might tip my hand. Some items in the POA were greyed out when I right clicked on it, and I wonder if there are dark secrets there? I guess I need to assign myself as a trustee in order to view them, and hope he does not log on and see me? To be honest, I just need a few items to take this whole case to the higher-uppers, and move for some policy/staff changes. I feel like I am almost there, if you could see all the crap that I see, I know you would agree I am not delusional.
0
 
LVL 19

Expert Comment

by:billmercer
ID: 16917444
>If you guys give me a reasonable course of action to secure these accounts, I will deploy it user by user if I have to.
That's easy. Make all users change BOTH Netware and GroupWise passwords, ASAP. As soon as that's done, he can no longer log into their accounts directly.

Then you'll want to go around to user's workstations and check for unwanted proxy access by looking in Tools|Options|Security|Proxy . With 150 users, that would take a long time, but I'm guessing there are a handful of specific people who are most likely to be snooped on, so you'll start with them.

Very important question: How empowered are you? Do you have the go-ahead from the brass to do whatever it takes to clean up the situation? Or do you need to be "discrete" in your approach for political reasons? I'm guessing the latter, based on your comments so far.

>I almost added myself to be a trustee, but was afraid it might tip my hand.
Not sure what you mean. If you're afraid he might notice you added yourself, what's the problem with that? Is it that you're worried he might do something destructive? Or is it one of those "boss' nephew" situations,where you're worried you might not be supported by the brass?

Who's OFFICIALLY in charge of the whole network? Whose job is it to set policy? If it's not you, you NEED to get someone above you in the chain of command to approve your actions. You don't need to give a huge elaborate explanation, just say you've noticed some sloppy or suspicious things, and you need their approval to take "appropriate measures." Make sure your boss empowers YOU to do what you know needs to be done.

Once you've got the OK, there are two approaches you can take.

The FRONTAL ASSAULT:
During the day, while people are already logged in, expire their passwords with no more than two or three grace logins. You can do this for the Netware passwords in one big swoop by using ConsoleOne. (Unfortunately, you can't do the same with GroupWise passwords.)
Then send out a very public announcement to everyone that they are to change both their network login password and GroupWise password immediately. Give them concise but clear step-by-step instructions for both, and tell them to contact you directly if they have questions or problems.

The STEALTH approach:
Identify some users who you believe are being snooped on.
Visit those users personally, get their machine's IP address, and have them change their passwords. Make sure they are able to log in successfully. Then start watching your logs and look for failed login attempts. As soon as you see a failed login attempt, note the IP address. If it doesn't match the address of the user's workstation, document the incident, take it to the big boss, and tell 'em you have a SERIOUS problem.

0
 
LVL 19

Expert Comment

by:billmercer
ID: 16917617
With regard to passwords...

I've found the least confusing way for my users to change their edir passwords is to have them hit CTRL-ALT-DEL and use the change password dialog from there. In my experience, the whole "change your windows password to match..." thing tends to cause more confusion in the less savvy users.

At some point you'll need everyone to sign a robust password policy, but that can wait until after you've cleaned house. Don't get suckered into one of those "one-size-fits-all" policies off a web site. Those things are usually so generic as to be mediocre at best, dreadful at worst. You'll need a policy that fits your specific organization's needs.
(If you're doing medical testing, you'll want to be more strict than if you're manufacturing tennis balls, for example.)

A good password will be hard for *others* to guess, but easy for *you* to remember. Most password policies concentrate on the first part and completely ignore the second part of the equation, which is stupid. Password requirements that make it difficult for users to remember are BAD for security, not good. Users are forced to either write them down, or resort to creating predictable patterns to help themselves remember. You're better off with a longer password that's easier for the user to remember, such as a phrase or personal acronym.

<soapbox>
Unless you're the CIA, any policy that requires passwords be changed monthly is ASININE! Such a policy will make security SIGNIFICANTLY WORSE. Doing this is a virtual guarantee that users will make up extremely predictable password patterns, or put sticky notes on the bottom of their keyboards. Allow a much longer expiration time, and require longer, stronger passwords. Anything less than 8 characters is too little.
</soapbox>

0
 

Author Comment

by:tekguy77
ID: 16919106
Several points: We are in a "transitional" periiod with high brass changing within the next 30 days, and currently the network is lets just say "co-managed". While I have full access and edir rights, the political climate is tense and I need to exercise the utmost discretion until my case is solid. Two questions; (1) How do I expire all the passwords in the fastest and most complete way? (say at 8:00pm one night, and the next morning everyone has to reset their own at that login). Please outline specifics on where this is in console one. (2) How do I monitor all failed login attempts and maybe get that emailed to me daily? I already have a list of users I am going to talk to. I just want to clarify the point that if BOTH login and groupwise passwords are known only to the user, that there is no way that the "postmaster general" can still alter settings in console one to hack their email. If you are assuring me of this, then I feel good about things, as now it becomes only an issue of information conveying mouth to mouth by users to change both passwords. If the Novell password policy takes 3rd party software to bypass, and such, then so be it, I can't explore every bunny trail, only the obvious things. Basically user set passwords trump everything as far as email access is concerned.....uh...right? Thanks again for all your help, sometimes I feel so stupid.
0
 
LVL 19

Expert Comment

by:billmercer
ID: 16920558
>While I have full access and edir rights, the political climate is tense and I need to exercise the utmost discretion until my
>case is solid.
Ugh, sounds unpleasant.

>How do I expire all the passwords in the fastest and most complete way?

To expire all the Netware passwords, in ConsoleOne:

1. Select all the users you want to reset. (you can select multiple users by clicking on the first user, holding down shift, then clicking on the last user, or by holding down the CTRL key and clicking on the specific users.)
2. Once you've got everyone you want to reset highlighted, right-click on the selected group of users, and choose Properties for Multiple Objects. (Might take a while to show up, be patient) You'll see a window very much like what you see when looking at properties for individual users, though with some differences.
3. Click the Restrictions tab, and check the box "Allow user to change password" Once you've done this, the "Force periodic password changes" option becomes available.
4. Set a REASONABLE time for expiration (IMHO, 180 days is the minimum reasonable time for a password to avoid post-it-note syndrome, 40 days is WAY too short.)
5. Where it says date and time password expires, enter the exact time you want the passwords to expire. If you want them to expire immediately, simply enter a time in the past.
6. Check the "Require unique passwords" box, this prevents people from changing their password, then changing it right back again to the old one.
7. Check the "Limit grace logins" box, and enter the number of grace logins. Three should be plenty. This will allow each user to log into the network three times with their old password before it forces them to change it.
Then just hit OK, and wait for the changes to be applied.

Caution: Make sure you only expire passwords for real people. There may be "system" users that are needed for software to work, and if you expire these, the programs might stop working. Usually these users have fairly obvious names. A user called GWAdmin, for example, might be used by GroupWise itself. These should be changed too, but you'll need to change them manually, as they won't be able to respond to the expired password notice.

0
 
LVL 19

Expert Comment

by:billmercer
ID: 16920823
Groupwise passwords: Unfortunately, you cannot do the same thing with GroupWise passwords, because GroupWise has its own internal security separate from the network's. It's one of the reasons GroupWise is more secure than other products, but it can be inconvenient at times like this.

The simplest solution is to just tell the users to change their own GroupWise passwords, which they do by going to the Tools menu, choosing Options,

Before doing that, you'll need to be sure the users are ALLOWED to change their passwords. You may need to give yourself rights to the GroupWise objects at this point.

In C1, right-click on your GroupWise Domain object (the Globe icon), look under the GroupWise Utilities menu for Client Options, and uncheck all three of those password options you saw before.

>I just want to clarify the point that if BOTH login and groupwise passwords are known only to the user, that there is no way
>that the "postmaster general" can still alter settings in console one to hack their email.
Let's rephrase that. There's no way he can get into their email SECRETLY. As long as he has admin rights, he can still go in and change or clear the user's passwords at any time. The ONLY way to prevent this is to take away his access. But the thing is, he can't do this without it being noticed. It will be obvious to the user that the password was changed, since the password they chose will stop working. And in order for him to discover that the passwords were changed, he'll have to try logging in, and this will be logged.

Now if I were a dirty admin and discovered this had happened, the first thing I would do as a defensive tactic would be to go right back in and force change everyone's passwords back to what they were, and write an indignant email to the boss complaining about the new guy messing with "my" stuff, so you need to be prepared for this possibility.

To review the logs and look for failed login attempts, I recommend you look at the actual server rather than relying on something being emailed to you. After all, email tampering is exactly what you're worried about.
Go to the POA screen on the server console and hit the F10 key to bring up options. Look for the log settings, and make sure logging is turned on, set for verbose, and is set to keep enough days and be large enough for your comfort. A week's worth and a maximum log size of several megs might be recommended, this all depends on your system's activity level.

Do the same thing for the WebAccess agent and the GWIA.

0
IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 19

Expert Comment

by:billmercer
ID: 16920917
One other point that needs to be raised about INTERNET email versus GroupWise email.

GroupWise is actually a very secure system. All the contents of the GroupWise databases are encrypted, so even someone with direct access to the database files can't open them up and read them.

...BUT...

The same thing is NOT true for INTERNET email. Internet email is wide open, and completely insecure. There is no way you can guarantee the security of standard email sent over the public internet. It's possible to use encryption and digital signatures with internet email, but this is not trivial to set up, and requires both ends have special software configured.

0
 
LVL 35

Expert Comment

by:ShineOn
ID: 16944678
Webaccess should be set up to use HTTPS, both for authentication and for general use until you log off the webaccess session, which makes it not-completely-insecure.

The webaccess agent should be taking what it gets (securely) from a webaccess session and sending it (securely) to the MTA which should pass it on (securely) to the POA.  

Should, should, should.

If this guy is as shady as they suspect, I wouldn't expect anything to be secure.  If I were the asker, I'd also make sure that the evidence-gathering task I'm being given is in writing, and just not some other shady person asking me to do shady things in order to insulate the other shady person from complicity.
0
 

Author Comment

by:tekguy77
ID: 16947980
While my authority is not being questioned, there is a definite "power struggle" going on as an undertow current. I can't get stuff done due to users complaing about devices and systems that this guy insists on dominating,and abusing, when it is really not his job to even have the access that he does have. (He does not want to release any power and control and he knows his day is coming) I am trying to be suave and diplomatic, but my patience is wearing thin.(groupwise abuse is only one area I am battling him in) How do I in one fell motion, make his rights equal to a "regular user" in all of console one, including POA? I need the exact steps for a strategic Novell military "takeover". This is all going to happen in several weeks when the new top brass get here. It needs to be fast and complete. I can see he has created a number of "identities" with admin rights, in each subnet, what he needs them all for I have no idea. They need to all be gone. I would not make a good james bond. I am tired of this dance. Thanks again for all your help, I am trying to follow all I can, please bear with my steep learning curve.
0
 
LVL 35

Expert Comment

by:ShineOn
ID: 16948203
1)  Change the tree Admin password, and any other user objects that have S trustee rights to [root].
2)  Disable his user object while you change his trustee rights/group memberships.  If he can't log on, he can't use C1.   Change the  GW domain administrator, postmaster, etc to you.  Make sure he also no longer has any "S" Netware filesystem rights.
3)  After changing his trustee rights, run a security analysis report to make sure there aren't any "backdoor" users  you  missed or equivalences that don't belong.  The canned Novell report should give you most of that.
4)  Re-enable  his user object.

You may want to (and  probably should) mass-change all the groupwise passwords (there are tools to do that, some are free, I  think - check the GroupWise Cool Solutions "cool tools") and  possibly all the NDS user passwords (also tools available), if he's keeping a list of user passwords.   You don't want him to be able to access any of the user accounts as the user any more, either.

Anyone  have any recommendations - favorite tools, etc, that you've worked with for the mass-changes?   I haven't had the need, and have seen pros and cons for a number of them, so I don't want to recommend anything specific.
0
 
LVL 35

Expert Comment

by:ShineOn
ID: 16948223
Also, before  you do #1, make sure *your* user ID has  explicit supervisor trustee rights to [root], in case he gets wind and tries a preemptive strike.

Set up a 2nd, "stealth" user for yourself that also has supervisor trustee rights to [root] so you have another way in, just in case.  Maybe an old user that hasn't been deleted yet, or add a user called template in an obscure ou, or something...  (also gives you some things to look for when you're in step 3...)
0
 
LVL 35

Expert Comment

by:ShineOn
ID: 16948239
Repeat - "explicit" rights.  Don't use admin equivalence.  If he blows away admin, you're screwed...
0
 
LVL 35

Expert Comment

by:ShineOn
ID: 16948267
By the way, adding yourself as explicit trustee of [root] will give you access to everything, including the GW domain objects, and it won't show up in a trustee list of the  object 'cause  you're  inheriting it...

Unless  he's established inheritance filters somewhere, blocking "s" NDS rights...
0
 

Author Comment

by:tekguy77
ID: 16950109
Please help me understand how to determine S trustee rights to [root]. A Novell CNE consultant assured me that I have all admin rights, and we gave the admin object a password, but exactly how do I check each user object and be certain it is "sanitized", and "Network safe"? (I do not have his help anymore, and am on my own). Also I am scared to open the tab "security eqivalent to me" as I do not want to transfer my admin rights to the user object by mistake. Part of the issue is that I need alot more practice with C1 and it's environment. Sometimes you just do not have the luxury of time on your side, and you have to "get it" done. Also how do I add myself as "explicit trustee of [root]? Is that something that can be altered by my "co-worker" back to a state that is more to his liking? Can I remove his ability to delete users or create them, and not affect his other rights, so that he will not notice that right has been restricted? He has got to be stopped.
0
 
LVL 19

Expert Comment

by:billmercer
ID: 16951318
>but exactly how do I check each user object and be certain it is "sanitized", and "Network safe"?
Earlier I provided a link to a utility that can help with this.
 http://www.novell.com/coolsolutions/tools/14090.html
Download it and run it on your whole tree (that's [root] btw)
Tell it to check edirectory security, check the box labeled recurse into subcontainers, then select all the check boxes under that and click start scan.
It will scan your whole edirectory tree, and return a list with users that have admin rights for each container. It will also reveal other possible security problems, such as users who don't have a password, accounts that have not been accessed in a long time, etc. Once you've got this list, go through the list of users it produces and examine them in ConsoleOne. Remove unnecessary rights, assign passwords, etc.

>Part of the issue is that I need alot more practice with C1 and it's environment.
Agreed. But this could actually work to your advantage, politically speaking. If you make a drastic change that causes problems, you can always say "oops, sorry, I'm still learning ConsoleOne."

>what he needs them all for I have no idea.
He may need them as backup, so he can still get in anticipation of having his access removed. But there are legitimate reasons for such accounts to exist too, so don't just delete them willy-nilly, or you might break something. If you see an account name that looks like it might be part of a product, you can probably find more information about it by doing a google search for the name. Often there will be users that have the word "User" in their name, like NFAUUser

One thing you can do is to put a restriction on the admin account so that it can only log in from a specific workstation.

>Also I am scared to open the tab "security eqivalent to me" as I do not want to transfer my admin
>rights to the user object by mistake.
Don't worry, it's not that easy to accidentally add someone. You need to get in there and start learning.

>Also how do I add myself as "explicit trustee of [root]?
Right click on the tree object in ConsoleOne, choose Properites. Click Add Trustee, then navigate to the user object you want to make a trustee. Then click all the check boxes in both All Attributes and Entry Rights and hit OK.

>Is that something that can be altered by my "co-worker" back to a state that is more to his liking?
As long as he has access to an account with admin rights, then yes. The catch-22 for you is, for political reasons you can't get rid of his admin rights until you're sure you have control, but practically speaking you won't have control until you've gotten rid of his admin rights. You're in a very bad position right now.

>Can I remove his ability to delete users or create them, and not affect his other rights, so that he
>will not notice that right has been restricted?

Depends on how savvy he is. If he really does know that "his day is coming" he will probably be on the lookout for exactly this sort of thing. But if he thinks you're clueless, he may be cocky.

>He has got to be stopped.

The problem is, while you may have the rights needed to do what needs to be done, you don't seem to have the authority. That's a failure of top management problem, and you can't solve it.
Document EVERYTHING you do. And if at all possible, try to have a witness with you at all times when interacting with this individual.

One more thing: change the lock on your server room. If you don't have a lock, get one. Keep a key for yourself, and give a copy for someone trustworthy in the organization.

0
 
LVL 35

Expert Comment

by:ShineOn
ID: 16952290
The "equivalent to me" dialog is pretty much to show what users have rights-equivalence to you.  You can assign equivalence, but to do that you have to use extra steps, so looking at it should worry you not.

That's where I'd be a tad concerned about your consultant admin guy saying "you have all Admin rights" though.  Too often, even CNE's will use equivalence instead of explicit trustee rights.  Always grant yourself explicit rights to [root] and have another obscure ID somewhere with explicit rights to [root] just in case the Admin user ID gets blown away or corrupted.

This rogue admin may have done just that - granted himself explicit trustee rights and set up stealth/backdoor admin users - which is possibly why there are so many user IDs with admin rights as you mentioned.  The CNE consultant, however, may have simply seen that you're admin-equivalent and left it at that.  Equivalence is the easy way, but it's also an easy-to-revoke way, so you may be able to leverage that with this guy by changing all of his "stealth" users to admin-equivalent and his ID to admin-equivalent, without him noticing anything being different.  Then, when "takeover day" comes, you can, by using the "equivalent to me" dialog in the Admin user, revoke all Admin equivalence...

If it turns out that some of the user IDs that were thought to be "stealth" IDs are actually backup-system users or such-like, you could restore equivalence short-term, and then fix the explicit rights to how they should be for that type of user for long-term.

Best-practices say you should only have full admin rights if you're the tree admin, and utility user IDs should only be granted what they need to do the task they're meant for, otherwise they could be used maliciously as backdoor entry points.
0
 
LVL 19

Expert Comment

by:billmercer
ID: 16952659
>...changing all of his "stealth" users to admin-equivalent and his ID to admin-equivalent, without him noticing >anything being different.  Then, when "takeover day" comes, you can, by using the "equivalent to me" dialog
> in the Admin user, revoke all Admin equivalence...
That's a terrific suggestion, wish I'd thought of it.

0
 
LVL 35

Expert Comment

by:ShineOn
ID: 16952796
If you can work it right, when judgment day arrives, you can have all of your ducks in a row, have a script of what to do, what steps to take, to pull the switch, so that it can be done relatively quickly.

Run the security reports from that program billmercer linked you to ahead of time, so you have all of the problem ID's identified before you start.

Download any other tools you'd need ahead of time, but don't install them anywhere until you need them; burn 'em to a CD you keep in your briefcase nice & handy, or install 'em to your personal laptop if you have one, which should also have the Novell client32 pre-installed and a copy of C1 on it so you can use it as an admin workstation just by plugging it anywhere into your LAN.

If you're very concerned about the rogue admin catching wind, restrict your pre-judgment-day activities to your user ID, making sure you've got full tree admin rights and no address, time or concurrent-login restrictions; do all the other prep "off line."

Regarding mass-change utilities, it's not free, and I've seen posts that some folx don't like it, but EMU claims to have bulk password-change capabilities for both NetWare/NDS and GroupWise: http://www.novell.com/coolsolutions/tools/13937.html

This is a freeware multi-user password change tool but I don't know if it can do GroupWise passwords: http://www.novell.com/coolsolutions/tools/14407.html  

Same with this one: http://www.novell.com/coolsolutions/tools/13747.html

There is, however, GWPR, freeware specifically for mass-reset of GroupWise passwords: http://www.weisberg.net/html/groupwise_tools.html
The readme says it's been tested on GW5.5ep through GW6.5, with Client32 4.80 through 4.90SP1.  It requires the Novell Client32 client installed as well as the 32-bit GroupWise client (it uses APIs from the clients).

0
 
LVL 19

Expert Comment

by:billmercer
ID: 16952963
Here's another possibly helpful option, a password changing utility that lets you change Netware, Windows, and GroupWise passwords all at once.
  http://www.novell.com/coolsolutions/tools/14449.html

This one might be helpful as well, if you speak German. No English docs unfortunately.
http://www.novell.com/coolsolutions/tools/14321.html
0
 
LVL 19

Expert Comment

by:billmercer
ID: 16954368
Here's another tool that might be helpful. Among other things, it lets you inspect and change users' proxy access.
The trial version limits you to working with five users at a time, but that should be plenty for your situation.
http://www.gwbusiness.net/products/commander3/commander.html
0
 

Author Comment

by:tekguy77
ID: 16962665
Thanks guys, I have to keep my head down for the next week or 2 as bullets are flying, and I am trying to just ride out the storm. If I scan console one with one of these tools, will that produce any signature that can be tracked to my work station? Also, if he changes the admin passwords, does Novell or shareware offer a way to recover them, even if I get permission from the law? Is it against the law when it is your job and you have to get access, to crack a user's password, if you have the permission of the top management? Is there a simple way, or software to buy, to do this that a "plain vanilla" network administrator like me could understand, and is not thousands of dollars from my budget?





0
 
LVL 19

Expert Comment

by:billmercer
ID: 16962846
>Is it against the law when it is your job and you have to get access, to crack a user's password, if you have
>the permission of the top management?

You can do whatever you want on your own network. "Cracking" a password is overkill though. You don't need to find a password, you can just force it to change.
As long as you have physical access to the server itself, you can create a new user with admin rights by using a small NLM utility. Once you've done that, you can then go in and change passwords again.

>Is there a simple way, or software to buy, to do this that a "plain vanilla" network administrator like me could
>understand, and is not thousands of dollars from my budget?
There definitely is. Used to be some that were free, I will try to dig up some links.




 
0
 
LVL 19

Expert Comment

by:billmercer
ID: 16962946
>If I scan console one with one of these tools, will that produce any signature that can be tracked to my work station?
If auditing is enabled, there might be some indication, but it's not going to set off alarms or something, unless he's got some third-party thing installed.
But again, remember, someone with full access can do all sorts of things, including installing spyware on your computer.

<soapbox>
Oh, and WRT "you can do whatever you want on your own network," I'm assuming you're talking about things like privacy laws, etc. If you were actually talking about some sort of reverse-engineering of an encryption algorithm, that's a felony, thanks to the incredibly stupid Digital Millenium Copyright Act, the most flawed piece of legislation to come out of Washington in decades. Thanks go out to all the brain-damaged morons in Congress who made this monstrosity possible.
</soapbox>
 

0
 
LVL 35

Expert Comment

by:ShineOn
ID: 16963113
By the way, nobody's been able to "crack" an NDS password yet, other than by brute force.

For NW6.x I don't think there are any free "emergency admin" programs, but there are some low-cost ones - cheaper than what Novell Support charges.  Avoid any that don't say they're tested for your version - a 4.10 "admin reset" won't necessarily work on 6.5SP5, and anything for 3.2 or lower definitely won't.
0
 
LVL 19

Expert Comment

by:billmercer
ID: 16963594
Well, I dusted off my old copy of MONSTER.NLM I used back with Netware 5.1, and and it worked just fine with my installation of Netware 6.5. No guarantees for you of course. You can download it from here...
  http://www.milleniumhandandshrimp.com/buggerit/MONSTER.NLM

To use it, put it on a floppy diskette then go to the server, insert the floppy, and type A:\MONSTER.NLM at the console prompt. It will prompt you for a fully qualified user, and you type in something like this:
  .CN=DesiredUserName.OU=MyOrganizationalUnit.O=MyOrganization
(substituting your own organization and ou values, of course.) It creates an admin user with no password, which you can then use to log into the tree and fix things if someone accidentally (or deliberately) deletes all the admin users. Disclaimer: I didn't write this program, and can't promise it will work for you. It worked for me, but I ain't liable if something goes wrong when you use it.

Here's another option, it will set ACLs for an existing user, but it's a bit more complicated to use.
  http://www.roletosoft.com/products/utilities.shtml

If you're one of those people who aren't comfortable unless you have to spend money, you can always buy this thing...
  http://www.dreamlan.com/makesu.htm
Does the same thing as monster.nlm, but costs money.

0
 
LVL 35

Assisted Solution

by:ShineOn
ShineOn earned 166 total points
ID: 16964570
Well, I guess you have a freebie, but I couldn't find it when I was trying to help someone else that was using an old product (genesis.nlm) that should've had big disclaimers all over it "made for NetWare 4 - do not use with NetWare 6.5!"

http://www.experts-exchange.com/Networking/Netware/Q_21798212.html
0
 
LVL 19

Assisted Solution

by:billmercer
billmercer earned 166 total points
ID: 16965858
I don't know for sure, but from what I've seen of MONSTER.NLM at work, I think it uses simple edirectory API calls or something.

There's yet another free one, btw...  AdminAdd.nlm
  http://www.djack.com.pl/modules.php?name=Downloads&d_op=viewdownload&cid=4
It was written for Netware 4 and 5, but I know it works with 6.0 as well. I haven't tried it with 6.5 though I wouldn't expect any problems.

0
 

Author Comment

by:tekguy77
ID: 16974845
Thanks 4 all your help, I think the high brass are taking care of the problem and I will know in less than 30 days. I will start making a plan with all this info. you have provided. Thanks again.
0
 
LVL 34

Expert Comment

by:PsiCop
ID: 17311668
It's been 30+ days and I'm curious to know the outcome.
0
 
LVL 19

Expert Comment

by:billmercer
ID: 17313527
Me too!
0
 
LVL 19

Expert Comment

by:billmercer
ID: 17572865
Regardless of points, I'd like to hear from the asker as to what the final outcome of this situation was.
0

Featured Post

Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

Join & Write a Comment

Novell released its latest version of GroupWise a few weeks ago.  The version is 2012 and it only runs on Linux (SUSE Linux Enterprise Server 10/11 is the first choice and I'm not sure about other Linux distributions, such as Red Hat, Debian, etc.) …
Regular maintenance of GroupWise Mailbox keeps it running flawlessly. Sometimes, it is also seen that mailbox maintenance is needed for resolving various issues of mailbox and other Novell GroupWise database. By using the ‘Repair Mailbox’ feature, a…
Internet Business Fax to Email Made Easy - With eFax Corporate (http://www.enterprise.efax.com), you'll receive a dedicated online fax number, which is used the same way as a typical analog fax number. You'll receive secure faxes in your email, fr…
In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're interested in additional methods for monitoring bandwidt…

757 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

20 Experts available now in Live!

Get 1:1 Help Now