This content has been marked as final. Show 8 replies
start at the beginning - what specifically is the problem? what errors have you got in front of you.
did you follow the "Device Encryption Quickstart Guide" to the letter? It will get you started.
from what you've said, do you actually have a database server set up and running? That's the key to the communication problems I think.
If you can't log in, then SB thinks you're typing the wrong password - so check your keyboard layout pre-boot (options button after cancelling login), and check you are typing the right password.
re subnets, don't worry about it - it's pure IP so if you can ping your server, the client will be able to communicate with it.
Will your company not pay for consulting services with McAfee to help you get this set up? Usually we have implementation planning included in every project...
Can you login to the SB console from the server itself, logging in as 'sbadmin' (unless you renamed) and whatever password you set?
I am on the server itself and can not login with sbadmin. I have another admin account in which i can not login with that one either. Both worked before now neither of them work.
Here are my 2 cents...
Any file sharing problem on your server? i.e. is your current Windows ID same as your admin/install ID or with equivlent access?
OR, have you "lock out" the admin account by trying too many time (how much re-try you allow in your sbadmin's password templete?)? i.e. if it's wrong password, SB will give you "invalid paramenter".. if you lock your account, SB will give you "invalid token"... invalid token, you need to create a new token...
I do hope this is just a test machine... it seems you are totally lock out... McAfee(SafeBoot) has a service to unlock for you, but (I heard) it will cost you LOTS!!! my experience tells me, I will create at least another admin account, which ONLY allow to access the management console on the server, but NOT assign to any machine/group... at same time, I also create a "viewer only" account for day to day usage....
If you really want to automate the solution, use your SB AD Connector to move user based on their AD membership... (although, I do not recommand to do so.... since, you are creating back door... for AD admin....)
PS: this is only my 2 cents and experience...
Sounds like you locked yourself out through bad password attempts, someone changed the password, or you demoted yourself from full admin status. You could try to cheat (with a copy of the production database, not the master).
Install a fresh copy of admin database on a spare machine (workstation, server, or VM). Configure only a basic template (enough to build a fresh account for SBAdmin), then copy SBDATA\00000001\* (exclude files directly in that base folder; should be very empty, since there is only one accont) over the top of a *copy* of your production database. Then try to login to that copy using the SBAdmin password you set during your fresh install.
If that works on your test server, you could then do the same thing to production server (since replacing the files would overwrite any forgotten passwords or changed privileges).
Never assign a level 32, super admin account to machines. They should be only for administration. This prevents accidental client side password changes/lockouts. Additionally, keep your admin accounts in a separate container than your normal AD/LDAP synched accounts (for that matter, no binding for admin accounts either). There should also be no AD/LDAP connector rules to put discovered accounts into admin groups (that would allow adn AD/LDAP admin to create a new account that would receive those rights at next AD/LDAP connect).
Moving an account between two databases will not help unless they are fragments of each other, as even though you'll be able to login with the moved account, it wont be valid for doing anything else on the db (you won't be able to open any machines, users etc.
Each DB's objects are locked cryptographically to stop this kind of thing going on, otherwise anyone with physical access to the SafeBoot server could get a high level access account just by installing a demo version and moving the account over.
Could the password be derived from SBSERVER.INI (which I think is the file that stores the password for starting up the database)?
The key is stored in that file for starting the database server service, not the password, and the user key never changes.
If you start the server manually as an app, it will give you a normal login prompt, so the key is not used. If the login prompt tells you that the password is wrong, then, quite simply, it is (though that may be because you put in the wrong user name, you're trying to login to the wrong database, or somehow you've got the wrong algorithm).