8 Replies Latest reply on Dec 3, 2008 8:31 AM by SafeBoot

    EndPoint issues (SafeBoot)

      :eek:

      Hello everyone (here goes nothing),

      This is my first time using SB, all I was given was the software in my hand and make it work statement.

      - My 2 admin accounts will not login SB Administration nor SB Database Sever now off the back I thought this was a service issue. Services SB Client Manager has started and SB HTTP Server has not. SB Client Manager is my focus though. I have stop and restarted but still can not login.

      - I have a client machine that will not login with either admin or user login on the SB screen. The login will timeout for increased amounts of time. I can try the User recovery process b/c I can not get in SB Administration on the Server. (doing some reading and found this out)

      - I can not find any documentation on using SB client on different subnets. Doesn't appear to act as HBSS and you can specify the IP and/or gateway. How can I sync to a client different from the SB Server.

      All of my experience with SB has been reading documentation...there doesn't seem to be a lot of document on google, cuil, dogpile etc. that can help. I use the Admin Guide and so forth. I have 400 machines to install the client on by 30 Dec 08. This is a headache for me.

      Any help would be great!!!

      Thanks,

      Julius
        • 1. RE: EndPoint issues (SafeBoot)
          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...
          • 2. RE: EndPoint issues (SafeBoot)
            Can you login to the SB console from the server itself, logging in as 'sbadmin' (unless you renamed) and whatever password you set?
            • 3. RE: EndPoint issues (SafeBoot)
              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.
              • 4. From my experience...
                HenryC
                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...
                • 5. RE: From my 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).
                  • 6. RE: From my experience...
                    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.
                    • 7. RE: From my experience...
                      Could the password be derived from SBSERVER.INI (which I think is the file that stores the password for starting up the database)?
                      • 8. RE: From my experience...
                        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).