We have some developers who work on the UNIX platform. The box is from Sun and runs Solaris. There is an Oracle database installed on the server. Developers use database accounts that are externally identified. That way they can authenticate once at the operating system level. They can then run their programs which call SQL*Plus and not need to re-enter the password. The access is externally identified. This setup stopped working this past week. The developers pushed the problem to the DBA Team.After a bit of investigation, the DBA Team found that the security people disabled the ability to connect via an externally identified account. The lead DBA was not happy. He let the software development manager deal with the security folks. The problem is that our DBAs are not the true DBAs for the databases we use. They have to go through the security people that actually manage the databases.
This is a very unusual setup. We are talking about development databases that have fabricated data. Yes there are some sensitive programs running on these boxes. But it is not that code which is locked down. It is the actual database (that has the dummy test data). Our DBAs are just our interface to the real DBAs from the security team. They have to make calls and send e-mail requests to the people with the real power.
The outcome of this backwards arrangement is that the whole team is at the mercy of the security folks. When they make and enforce new policies, the dev team suffers. At this point it is up to management to fight the security Nazis. Some developers are in work stoppage status right now. I feel their pain. It seems these problems happen once a year. Is somebody over there in security getting bored and having fun at our expense?
