Tensions between developers and administrators sometimes run rife. A developer is building complex systems and this often involves installing and reinstalling many different pieces of software on a variety of machines. Things can be left undone, or deliberately designed to make the development process less bogged down by mundane tasks that detract from the developer's keen thought-process.
January 31, 2001
The administrator is, of course, a highly valued member of the team, but has a slightly different agenda, which may conflict with the developer's need to get thinks done. After all, the administrator is concerned about things like security!
In this series of articles we'll look at some of the things developers do - with the best intentions, of course - that make an administrator's blood boil, starting with misuse of administrative logins.
Do you use administrative logins to all your databases or servers? Developers often rebuild their systems time and time again. It may seem quick and harmless to use privileged accounts for everyday tasks, or to retain default passwords.
How many times have you set up a connection to an SQL Server database with username sa and a blank password? Or, to Oracle using the username system and password manager? Or to Interbase with username sysdba and password masterkey? Or, indeed, how many times have you logged onto a Windows NT computer with a username of Administrator and the password either blank or password?
Even the "big guys" are guilty of this. Even SAP R/3, that monolithic enterprise system, creates its own database user (say, sapsa in SQL Server) and leaves the original unmodified. Not only this, but because one of the very first steps in any SAP R/3 installation is to make a copy of the default 000 client for actual use, the SAP* password is still commonly kept at its default value. Maybe a lot of developers don't realise this, but the end result is that an SAP R/3 system can very well have an SQL Server database that still has a blank password for sa, and a default SAP* password of either 19920706 or pass for client 000.
If you're using SAP R/3, run the RSUSR003 program from the ABAP workbench and the number of accounts among your clients that still have a default password might surprise you.
Ultimately, and needless to say, this is bad form.
It may well be quick - especially when rebuilding your machines time and time again - to keep all the passwords at the default, and to just use privileged accounts for all and sundry purposes. However, what happens if your system becomes the production system and you don't have the time to check just how many privileges your system needs - or to change all the password and accounts?
The SAP story above is real - and maybe this is remiss of me to tell you - but it's probably likely that an SAP system with an SQL Server database still has an sa username with a blank password - and it can be connected to just by using Enterprise Manager from another PC.
Don't let your site be as easily compromised by what amounts to simple neglect!
David Williams is a computer consultant in Newcastle, Australia. Projects include an ASP-based task logging system for a University help desk environment, and 'hack-proofing' an evaluation version of a package to manage mobile phone shops.
