Re: oracle authentication from windows
Multiple users with the same name may exist in different domain, just as the docs state. Using OSAUTH_PREFIX_DOMAIN = true requires that the domain name be part of the username for externally authenticated accounts. scott/tiger would become your_domain\scott/tiger Jared <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 06/27/2003 12:44 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> cc: Subject: Re: oracle authentication from windows Thanks reginald, Jared , Mladen,.. I set sqlnet.authentication_services=(nts) made sure that the ntlm service was up and running and created a user by the name \\domain_name\username ( replaced domain_name with the name of the stand alone computer i was testing this on) and I can now log in operating system users with remote_os_authent=false Thanks a lot list Could anyone please explain the significance and working of OSAUTH_PREFIX_DOMAIN. I read the following but was unable to understand it : "" There may be multiple frank usernames on your network, including local user frank, domain user frank on sales, and possibly several domain users frank on other domains. Entering true enables the server to differentiate among them. Entering false causes the domain to be ignored and local user frank to become the default value of the operating system user returned to the server."" The security and network integration guide for windows also says this about setting registry parameter osauth_prefix_domain : ""Do this step only if you are not authenticating a domain name with a user (for example, just frank instead of frank on domain sales). "" Could someone please explain the above quoted docs. . - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Monday, June 23, 2003 19:24 : : Try authenticating with the domain\userid. When you create the user : account in the database, use the domain\userid. Set : SQLNET.AUTHENTICATION_SERVICES = (NTS) in the sqlnet.ora file. Check out : MetaLink note 60634.1 on how to set up domain authenticated users. Also : set the registry entry OSAUTH_PREFIX_DOMAIN and create userids in the form : of OPS$\ . For users on the local server, their domain would : be the local server. All others domains would be their actual NT domain. : Check out the MetaLink document for more details. : : RWB : : == == : : Reginald W. Bailey : IBM Global Services - ETS SW GDSD - Database Management : Your Friendly Neighborhood DBA : 713-216-7703 (Office) 281-798-5474 (Mobile) 713-415-5410 (Pager) : == == : : : : [EMAIL PROTECTED] : dia.net.in To: [EMAIL PROTECTED] : Sent by: cc: : [EMAIL PROTECTED] Subject: Re: oracle authentication from windows : com : : : 06/21/2003 08:49 : PM : Please respond to : ORACLE-L : : : : : : : Thank you very much Arup , very lucid and detailed explanation. : In the last point you said : : :3) If remote_os_authent is false, but the database has a user : OPS$BULBUL : : identified externally; a user named bulbul on the _server_ can login : as : : "sqlplus /", but a user named BULBUL on a remote machine will not be : able : : to. : That is the problem , as I said I am not able to log in even the : database server's operating system users ( who are identified : externally ) unless I set remote_os_authent= true ; But then as you : said any remote client could authenticate the externally identified : user in whatever means, and then they could log in. I mean : create user scott identified externally; : grant create session to scott ; : If on the client machine there is an operating system user called : scott, then he can log in to the scott schema. : Any ideas how to restrict the externally identified users so that they : have to log in to the database server to access their oracle schemas.? : : Another doubt is from what you said about : sqlnet_authentication_services : : : You are using (none) because you do not want to rely on the : authentication : : service provided by others. : : : So this means that the database will not recognise the authentication : done by some other means ( like the white house guards refusing to : recognize the authentication provided by the people on the hill). : Then how will someone log in if he is identified externally ? : : Once again thanks for the excellent response, thanks for taking time : out to explain the physical significance of these
Re: oracle authentication from windows
Thanks reginald, Jared , Mladen,.. I set sqlnet.authentication_services=(nts) made sure that the ntlm service was up and running and created a user by the name \\domain_name\username ( replaced domain_name with the name of the stand alone computer i was testing this on) and I can now log in operating system users with remote_os_authent=false Thanks a lot list Could anyone please explain the significance and working of OSAUTH_PREFIX_DOMAIN. I read the following but was unable to understand it : "" There may be multiple frank usernames on your network, including local user frank, domain user frank on sales, and possibly several domain users frank on other domains. Entering true enables the server to differentiate among them. Entering false causes the domain to be ignored and local user frank to become the default value of the operating system user returned to the server."" The security and network integration guide for windows also says this about setting registry parameter osauth_prefix_domain : ""Do this step only if you are not authenticating a domain name with a user (for example, just frank instead of frank on domain sales). "" Could someone please explain the above quoted docs. . - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Monday, June 23, 2003 19:24 : : Try authenticating with the domain\userid. When you create the user : account in the database, use the domain\userid. Set : SQLNET.AUTHENTICATION_SERVICES = (NTS) in the sqlnet.ora file. Check out : MetaLink note 60634.1 on how to set up domain authenticated users. Also : set the registry entry OSAUTH_PREFIX_DOMAIN and create userids in the form : of OPS$\ . For users on the local server, their domain would : be the local server. All others domains would be their actual NT domain. : Check out the MetaLink document for more details. : : RWB : : == == : : Reginald W. Bailey : IBM Global Services - ETS SW GDSD - Database Management : Your Friendly Neighborhood DBA : 713-216-7703 (Office) 281-798-5474 (Mobile) 713-415-5410 (Pager) : == == : : : : [EMAIL PROTECTED] : dia.net.in To: [EMAIL PROTECTED] : Sent by: cc: : [EMAIL PROTECTED] Subject: Re: oracle authentication from windows : com : : : 06/21/2003 08:49 : PM : Please respond to : ORACLE-L : : : : : : : Thank you very much Arup , very lucid and detailed explanation. : In the last point you said : : :3) If remote_os_authent is false, but the database has a user : OPS$BULBUL : : identified externally; a user named bulbul on the _server_ can login : as : : "sqlplus /", but a user named BULBUL on a remote machine will not be : able : : to. : That is the problem , as I said I am not able to log in even the : database server's operating system users ( who are identified : externally ) unless I set remote_os_authent= true ; But then as you : said any remote client could authenticate the externally identified : user in whatever means, and then they could log in. I mean : create user scott identified externally; : grant create session to scott ; : If on the client machine there is an operating system user called : scott, then he can log in to the scott schema. : Any ideas how to restrict the externally identified users so that they : have to log in to the database server to access their oracle schemas.? : : Another doubt is from what you said about : sqlnet_authentication_services : : : You are using (none) because you do not want to rely on the : authentication : : service provided by others. : : : So this means that the database will not recognise the authentication : done by some other means ( like the white house guards refusing to : recognize the authentication provided by the people on the hill). : Then how will someone log in if he is identified externally ? : : Once again thanks for the excellent response, thanks for taking time : out to explain the physical significance of these parameters in a very : nice way. : : : : : (2) remote_os_authent means the user is authenticated in whatever : manner in : : the _client_ operating system, not the server. The user may have no : account : : with the server. : : : : (3) If remote_os_authent is false, but the database has a user : OPS$BULBUL : : identified externally; a user named bulbul on the _server_ can login : as : : "sqlplus /", but a user named BULBUL on a remote machine will not be : able : : to. : : : : Hope this helps. : : : : Arup Nanda : : www.proligence.com :
Re: oracle authentication from windows
Arup,
thanks for your detailed feedback
Comments inline
>
>(1) The use of remote_os_authent is false, then it simply means that users
>from another machine can't log in using OPS$ accounts. Needless to say, this
>reduces the security and must be weighed a bit more carefully than usual.
>
Here I think you meant to say remote_os_authent =TRUE (not false) is a
security
risk to ponder carefully
>(2) Should you ever have accounts externally identified? I would say, yes,
>as long as you know the privileges are not sweeping.
Agreed, particularly useful to avoid passwords in batch jobs
>(3) Having said that, the next question is - should you leave the value of
>os_authent_prefix at NULL (""). I say absolutely not. Here is the probelm
>with an externally idefoaable user with os_authent_prefix set to null. A
>user OPS$SCOTT identified externally is no the same as SCOTT, if the
>os_authent_prefix is set to OPS$. If that parameter is null, then database
>user SCOTT is the same as the OS user SCOTT. If someone creates a user in
>the OS called "system" and os_authent_prefix is null, what is the database
>user it connects to? SYSTEM Would you want that? Of couse not. That is
>why you never, ever, want to set the os_authent_prefix to null. Always set
>it to a value. You may have a different value such as UNSAFE$, if you wish,
>to fool the hackers.
>
That's where I don't follow you :
It connects to SYSTEM ONLY if I have declared SYSTEM identified EXTERNALLY
in the database.
So the security problem resides in the choice of EXTERNALLY identified users
and we are back to (2) above.
>(4) Thank you for the example. I guess I was not very clear on that issue. I
>think the original question from Bulbul was how to prevent the OPS$ useers
>from connecting to the database using user id, isn't that so, Bulbul? The
>solution is rather simple. Just use either of the two forms of the command
>"create user OPS$SCOTT identified externally" or create user SCOTT
>identified by tiger", not "create user OPS$SCOTT identified by tiger". And
>always set your os_authent_prefix to OPS$ or some non-null value. This way
>the accounts will be authenticated in only one way, not both.
>
>Another trick I use to foll th ehackers using the brute force attack is to
>use the construct
>
>alter user ops$scott identified by values 'somestringinascii'
>
In fact the syntax "create user ops$scott identified externally" already
translates to
create user ops$scott identified by values 'EXTERNAL'
>Since the password is hashed and digestedm this will not match any password
>and therefore will not correspond to a value.
>
As an aside, if you do this for sys password AND have a password file
(i.e orapw) use a value of exactly 16 characters - the hash is stored
internally in varchar2(16) - or you will get some ORA-00600 when using the
password file
with a user not member of the OSDBA group.
For this case, I suggest to use the value ' No Login' (notice the 16c)
>By the way, Gilles, the connection will work fine with the userid as a
>parameter to the sqlplus command. Are you using unix? If so, use
>
>sqlplus ops\$arup/nanda (note the backslash before the $ sign)
>>instead of
>>sqlplus ops$arup/nanda
>
>$ sign being a unix special character may have confused sqlplus, thinking
>$arup/nanda being an environmental variable.
>
Correct that was it
>HTH.
>
>Arup
>
>
>
>- Original Message -
>To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
>Sent: Tuesday, June 24, 2003 5:19 PM
>
>
>> Hi Arup,
>>
>> At 21:59 21/06/2003 -0800, you wrote:
>> ...
>>
>> >An OS user called scott will be able to connect as the database user
>> >OPS$SCOTT, not SCOTT - a big difference. This is why the
>os_authent_prefix
>> >parameter is so important to set; don't leave it as null. If it is null,
>> >then the OS user scott can connect to database user scott.
>> >
>> Maybe I miss the obvious..
>> Considering remote_os_authent=false, why for LOCAL connections
>> os_authent_prefix='' is inherently less secure than os_authent_prefix=OPS$
>> or whatever string you choose.
>> In each case, the prerequisite is to create the user "identified
>externally"
>> (that's where you MUST be cautious)
>> But if scott is created with a password (i.e create user scott identified
>> by tiger)
>> then no OS user scott can log on whatever the os_authent_prefix is.
>> At least that's how I understand the feature.
>> Can you please elaborate on the security issue ?
>>
>> >> Any ideas how to restrict the externally identified users so that they
>> >> have to log in to the database server to access their oracle schemas.?
>> >
>> >Well, they are mutually exclusive. A user is authenticated by either the
>> >database or externally, not both. So if you create user scott identified
>> >externally, you are allowing him to bypass database authentication. If
>you
>> >don't want that, then you would create user SCOTT identified by a
>password.
>> >
>> In fact if os_authent_prefix=
Re: oracle authentication from windows
Gilles,
Here is a lowdown on the security aspects related to the OS authentication.
(1) The use of remote_os_authent is false, then it simply means that users
from another machine can't log in using OPS$ accounts. Needless to say, this
reduces the security and must be weighed a bit more carefully than usual.
(2) Should you ever have accounts externally identified? I would say, yes,
as long as you know the privileges are not sweeping. For instance, you
definitely don't want to give DBA privs to an externally identifiable user.
(3) Having said that, the next question is - should you leave the value of
os_authent_prefix at NULL (""). I say absolutely not. Here is the probelm
with an externally idefoaable user with os_authent_prefix set to null. A
user OPS$SCOTT identified externally is no the same as SCOTT, if the
os_authent_prefix is set to OPS$. If that parameter is null, then database
user SCOTT is the same as the OS user SCOTT. If someone creates a user in
the OS called "system" and os_authent_prefix is null, what is the database
user it connects to? SYSTEM Would you want that? Of couse not. That is
why you never, ever, want to set the os_authent_prefix to null. Always set
it to a value. You may have a different value such as UNSAFE$, if you wish,
to fool the hackers.
(4) Thank you for the example. I guess I was not very clear on that issue. I
think the original question from Bulbul was how to prevent the OPS$ useers
from connecting to the database using user id, isn't that so, Bulbul? The
solution is rather simple. Just use either of the two forms of the command
"create user OPS$SCOTT identified externally" or create user SCOTT
identified by tiger", not "create user OPS$SCOTT identified by tiger". And
always set your os_authent_prefix to OPS$ or some non-null value. This way
the accounts will be authenticated in only one way, not both.
Another trick I use to foll th ehackers using the brute force attack is to
use the construct
alter user ops$scott identified by values 'somestringinascii'
Since the password is hashed and digestedm this will not match any password
and therefore will not correspond to a value.
By the way, Gilles, the connection will work fine with the userid as a
parameter to the sqlplus command. Are you using unix? If so, use
sqlplus ops\$arup/nanda (note the backslash before the $ sign)
instead of
sqlplus ops$arup/nanda
$ sign being a unix special character may have confused sqlplus, thinking
$arup/nanda being an environmental variable.
HTH.
Arup
- Original Message -
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Tuesday, June 24, 2003 5:19 PM
> Hi Arup,
>
> At 21:59 21/06/2003 -0800, you wrote:
> ...
>
> >An OS user called scott will be able to connect as the database user
> >OPS$SCOTT, not SCOTT - a big difference. This is why the
os_authent_prefix
> >parameter is so important to set; don't leave it as null. If it is null,
> >then the OS user scott can connect to database user scott.
> >
> Maybe I miss the obvious..
> Considering remote_os_authent=false, why for LOCAL connections
> os_authent_prefix='' is inherently less secure than os_authent_prefix=OPS$
> or whatever string you choose.
> In each case, the prerequisite is to create the user "identified
externally"
> (that's where you MUST be cautious)
> But if scott is created with a password (i.e create user scott identified
> by tiger)
> then no OS user scott can log on whatever the os_authent_prefix is.
> At least that's how I understand the feature.
> Can you please elaborate on the security issue ?
>
> >> Any ideas how to restrict the externally identified users so that they
> >> have to log in to the database server to access their oracle schemas.?
> >
> >Well, they are mutually exclusive. A user is authenticated by either the
> >database or externally, not both. So if you create user scott identified
> >externally, you are allowing him to bypass database authentication. If
you
> >don't want that, then you would create user SCOTT identified by a
password.
> >
> In fact if os_authent_prefix=OPS$ and ONLY in this case,
> you can still do this (it's inherited from V6 days but still working
> with Oracle 9i R2) :
>
> create user ops$arup identified by nanda;
> grant create session to ops$arup;
> And know you can either connect with
> sqlplus /
> or
> sqlplus /nolog
> connect ops$arup/nanda
> or
> sqlplus /nolog
> connect ops$arup
> password : nanda
>
> Although it doesn't work directly from the command line
> like sqlplus ops$arup/nanda
> or sqlplus ops$arup
> password : nanda
> (But works again after you get
> Enter username for a 2nd try)
>
> Regards
>
>
> Gilles Parc
>
> carpe diem !!
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Gilles PARC
> INET: [EMAIL PROTECTED]
>
> Fat City Network Services-- 858-538-5051 http://www.fatcity.com
> San Diego, California-- Mailing list and web hosting services
> -
Re: oracle authentication from windows
Hi Arup, At 21:59 21/06/2003 -0800, you wrote: ... >An OS user called scott will be able to connect as the database user >OPS$SCOTT, not SCOTT - a big difference. This is why the os_authent_prefix >parameter is so important to set; don't leave it as null. If it is null, >then the OS user scott can connect to database user scott. > Maybe I miss the obvious.. Considering remote_os_authent=false, why for LOCAL connections os_authent_prefix='' is inherently less secure than os_authent_prefix=OPS$ or whatever string you choose. In each case, the prerequisite is to create the user "identified externally" (that's where you MUST be cautious) But if scott is created with a password (i.e create user scott identified by tiger) then no OS user scott can log on whatever the os_authent_prefix is. At least that's how I understand the feature. Can you please elaborate on the security issue ? >> Any ideas how to restrict the externally identified users so that they >> have to log in to the database server to access their oracle schemas.? > >Well, they are mutually exclusive. A user is authenticated by either the >database or externally, not both. So if you create user scott identified >externally, you are allowing him to bypass database authentication. If you >don't want that, then you would create user SCOTT identified by a password. > In fact if os_authent_prefix=OPS$ and ONLY in this case, you can still do this (it's inherited from V6 days but still working with Oracle 9i R2) : create user ops$arup identified by nanda; grant create session to ops$arup; And know you can either connect with sqlplus / or sqlplus /nolog connect ops$arup/nanda or sqlplus /nolog connect ops$arup password : nanda Although it doesn't work directly from the command line like sqlplus ops$arup/nanda or sqlplus ops$arup password : nanda (But works again after you get Enter username for a 2nd try) Regards Gilles Parc carpe diem !! -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Gilles PARC INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: oracle authentication from windows
Arup,
Do you include info on setting 'OSAUTH_PREFIX_DOMAIN' in the registry?
If not set then cross-domain externally identified accounts must be
created as OPS$domain\username, which is a bit of a pain.
Security may require it though.
Jared
On Thursday 19 June 2003 15:34, Arup Nanda wrote:
> Mladen,
>
> This is precisely the content I have gone in depth in my upcoming book
> where this practice of OPS$ accounts have been discussed.
>
> The security hole in OPS$ accounts is a bit overrated. Chagnign username in
> Windows XP alone does not allow logging in to the database directly if OPS$
> accounts are used. What you are referring to is setting the ORA_DBA group
> in Windows. Here is an excerpt from the book:
>
> "If OPS$ accounts must be used, make sure that init.ora parameter
> os_authent_prefix is set to OPS$ or some other value, not NULL. If it is
> null, as shown by an empty string "", the security is severely threatened.
> Any one can create a userid called SYSTEM in the OS and then logon without
> a password as the Oracle user SYSTEM. If the os_authent_prefix is set to
> OPS$, then the corresponding user id in Oracle will be OPS$SYSTEM, not
> SYSTEM. they are different users."
>
> As you might notice, OPS$ accounts are somehow insecure, and I personally
> eschew them; but let's face it, in some situations, like in the case AK
> mentioned, the use is required. When the DBAs can do is to take some
> precautions to ensure security.
>
> HTH.
>
> Arup
> - Original Message -
> From: Gogala, Mladen
> To: Multiple recipients of list ORACLE-L
> Sent: Thursday, June 19, 2003 4:19 PM
> Subject: RE: oracle authentication from windows
>
>
> That, of course, will render your database totally insecure and open to
> anybody who can bring in a WinXP laptop, change the windoze username and
> log in as he pleases. DBA that sets his production parameters the way Arup
> described deserves to be publicly tortured by Bill O'Reilly in the "no spin
> zone".
>
> Mladen Gogala
> Oracle DBA
> Phone:(203) 459-6855
> Email:[EMAIL PROTECTED]
>
> -Original Message-----
> From: Arup Nanda [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 19, 2003 3:46 PM
> To: Multiple recipients of list ORACLE-L
> Subject: Re: oracle authentication from windows
>
>
> Sure.
>
> Just declare these in your init.ora
>
> os_authent_prefix=OPS$
> remote_os_authent=TRUE
>
> bounce the database, add a user called OPS$, e.g.
> OPS$AK if your Windows login id is AK as
>
> create user ops$ak identified externally
>
> From windows connect as "/@servicename", e.g. sqlplus /@service1
>
> If it doesn't work, the OS user may be different. Use this query while
> connected to the database from Windows cleint.
>
> SQL> select sys_context('USERENV','OS_USER') from dual;
>
> See what OS username comes up; use that instead.
>
> HTH.
>
> Arup Nanda
> www.proligence.com
>
>
> - Original Message -
> From: AK
> To: Multiple recipients of list ORACLE-L
> Sent: Thursday, June 19, 2003 1:10 PM
> Subject: oracle authentication from windows
>
>
> We want our client users ( forms user ) to just enter windows
> password and then automatically able to get in to oracle .Is there a way
> oracle can authenticate from windows ( or active directory ) . enbadding
> password in runform.exe not an option .
>
> thanks,
> -ak
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Jared Still
INET: [EMAIL PROTECTED]
Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Re: oracle authentication from windows
Try authenticating with the domain\userid. When you create the user account in the database, use the domain\userid. Set SQLNET.AUTHENTICATION_SERVICES = (NTS) in the sqlnet.ora file. Check out MetaLink note 60634.1 on how to set up domain authenticated users. Also set the registry entry OSAUTH_PREFIX_DOMAIN and create userids in the form of OPS$\ . For users on the local server, their domain would be the local server. All others domains would be their actual NT domain. Check out the MetaLink document for more details. RWB Reginald W. Bailey IBM Global Services - ETS SW GDSD - Database Management Your Friendly Neighborhood DBA 713-216-7703 (Office) 281-798-5474 (Mobile) 713-415-5410 (Pager) [EMAIL PROTECTED] dia.net.in To: [EMAIL PROTECTED] Sent by: cc: [EMAIL PROTECTED] Subject: Re: oracle authentication from windows com 06/21/2003 08:49 PM Please respond to ORACLE-L Thank you very much Arup , very lucid and detailed explanation. In the last point you said : :3) If remote_os_authent is false, but the database has a user OPS$BULBUL : identified externally; a user named bulbul on the _server_ can login as : "sqlplus /", but a user named BULBUL on a remote machine will not be able : to. That is the problem , as I said I am not able to log in even the database server's operating system users ( who are identified externally ) unless I set remote_os_authent= true ; But then as you said any remote client could authenticate the externally identified user in whatever means, and then they could log in. I mean create user scott identified externally; grant create session to scott ; If on the client machine there is an operating system user called scott, then he can log in to the scott schema. Any ideas how to restrict the externally identified users so that they have to log in to the database server to access their oracle schemas.? Another doubt is from what you said about sqlnet_authentication_services : : You are using (none) because you do not want to rely on the authentication : service provided by others. : So this means that the database will not recognise the authentication done by some other means ( like the white house guards refusing to recognize the authentication provided by the people on the hill). Then how will someone log in if he is identified externally ? Once again thanks for the excellent response, thanks for taking time out to explain the physical significance of these parameters in a very nice way. : (2) remote_os_authent means the user is authenticated in whatever manner in : the _client_ operating system, not the server. The user may have no account : with the server. : : (3) If remote_os_authent is false, but the database has a user OPS$BULBUL : identified externally; a user named bulbul on the _server_ can login as : "sqlplus /", but a user named BULBUL on a remote machine will not be able : to. : : Hope this helps. : : Arup Nanda : www.proligence.com : : - Original Message - : To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> : Sent: Saturday, June 21, 2003 2:19 AM : : : >
Re: oracle authentication from windows
Hi Beth, See in Aarons book page 196, second paragraph for changing domain names on win 95,98 untrusted clients. Perhaps i wasn't clear what i was saying is that it is possible to connect to the database from a PC that is not authenticated on the domain using an untrusted client. Have a look at James Abendshands tnscmd.pl script at http://www.jammed.c om/~jwa/hacks/security/tnscmd and also Patrik Karlsson's site for his oracle tools http://www.cqure.net to get some ideas. cheers Pete In article <[EMAIL PROTECTED]>, Seefelt, Beth <[EMAIL PROTECTED]> writes > >Hi Pete, > >I don't think that's true about booting a PC with the same domain name >that's not really part of the domain. Have you ever tried it? I'd be >really interested if it works. > >I don't understand the part about booting into Linux and changing the >username as its sent. Isn't the only username passed / ? Or are you >talking about poking things at the packet level to make sqlnet think the >user is domain authenticated. > >Cheers, > >Beth > >-Original Message- >Sent: Friday, June 20, 2003 6:49 PM >To: Multiple recipients of list ORACLE-L > > >Hi Beth > >OK, I get your point but Arup was talking about automatic connections by >setting remote_os_authent to true where you can either set the prefix to >OPS$ or use identified externally. For these connections the user should >not be prefixed by the domain name in the database. On the other hand >using windows NT authentication and prefixing with the domain name can >be spoofed by using a client that is not trusted such as windows 95 or >98 and setting the context to any domain you wish and adding the correct >user. The other option is to insert a linux bootable CD and alter the >username as it is sent. > >I agree with you that use of the domain method is better, BUT the point >i was trying to make is still valid. That is to ensure that any external >account observes the least privilege principle. > >cheers > >Pete > > > >In article <[EMAIL PROTECTED]>, Seefelt, Beth ><[EMAIL PROTECTED]> writes >> >>I disagree. Remote OS authentication is not inherently insecure in >>Windows like it is in Unix. If you prefix the account names with the >>domain name, a user would not only have to spoof the username, he would > >>have to spoof the domain name too. At that point, you probably have >>bigger problems than access to your database. Also, in that situation, > >>only the security token is going over the network, not your password in > >>clear text. The caveat is that you should be using the *domain name* >>as the prefix, not OPS$. >> >>-Original Message- >>Sent: Friday, June 20, 2003 6:20 AM >>To: Multiple recipients of list ORACLE-L >> >> >>Hi Arup, >> >>Remote OS authentication whether with OPS$ or not is still a risk. You >>are intimating that SYSTEM is the only risky account involved here. >>What if any of the newly created OPS$ accounts have useful privileges. >>I have seen a similar application to the one described recently. There >>were forms within the application for administration and user >>management (in oracle, not the application) and the users who had >>access to these were assigned the DBA role and were of course external >>accounts. >> >>I think what you should add to your comment is that the issue is >>overrated is that any OPS$ / external accounts should not have any >>dangerous privileges granted and certainly not DBA. If you can guess >>the name of an admin account even if its OPS$ then the issue is still >>severe. >> >>cheers >> >>Pete >> >>-- >>Pete Finnigan >>email:[EMAIL PROTECTED] >>Web site: http://www.petefinnigan.com - Oracle security audit >>specialists >>Book:Oracle security step-by-step Guide - see http://store.sans.org for >>details. >> >>-- >>Please see the official ORACLE-L FAQ: http://www.orafaq.net >>-- >>Author: Pete Finnigan >> INET: [EMAIL PROTECTED] >> >>Fat City Network Services-- 858-538-5051 http://www.fatcity.com >>San Diego, California-- Mailing list and web hosting services >>- >>To REMOVE yourself from this mailing list, send an E-Mail message >>to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the > >>message BODY, include a line containing: UNSUB ORACLE-L (or the name of > >>mailing list you want to be removed from). You may also send the HELP >>command for other information (like subscribing). >>-- >>Please see the official ORACLE-L FAQ: http://www.orafaq.net > >-- >Pete Finnigan >email:[EMAIL PROTECTED] >Web site: http://www.petefinnigan.com - Oracle security audit >specialists Book:Oracle security step-by-step Guide - see >http://store.sans.org for details. > >-- >Please see the official ORACLE-L FAQ: http://www.orafaq.net >-- >Author: Pete Finnigan > INET: [EMAIL PROTECTED] > >Fat City Network Services-- 858-538-5051 http://www.fatcity.com >San Diego, California-- Mailing list and web hosting servi
Re: oracle authentication from windows
Beth when the whole setup uses a workgroup and people log into their local machines rather than being authenticated by a domain server ? - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Monday, June 23, 2003 03:34 : : No, that's not true. It actually uses your NT security token to : validate that you are authenticated in the domain. You can't just give : a rogue PC the same domain name, boot it up, and log into the database : with external authentication. The PC would have to be a domain member, : which means you have to have the domain admin password to join the : domain, along with the users password so that you could log into the : domain as them. The same is not true if you use another prefix such as : OPS$. : : : -Original Message- : Sent: Friday, June 20, 2003 4:00 PM : To: Multiple recipients of list ORACLE-L : : : Beth, : : You are right in stating that OPS$ accounts are not inherently insecure. : : How is teh inclusion of domain name any more secure than using OPS$? : Granted, the hacker has to guess the domain name in addition to user : name, but so is using any other prefix other than OPS$. : : Besides if the users are not static, the domain names will be different. : How will you address that issue? For instance, you domina name is : MYCODOMAIN1 and your windows userid is mycodomain1\bseefelt, so the : Oracle userid, as you propose should be "mydomain\bseeth". If you login : to another domain, say, MYDOMAIN2, this account is no longer valid. So, : I would say, mixing domains with username may not be a good idea, unless : ofourse you have a single domain. : : Arup : : : - Original Message - : To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> : Sent: Friday, June 20, 2003 10:10 AM : : : > : > I disagree. Remote OS authentication is not inherently insecure in : > Windows like it is in Unix. If you prefix the account names with the : > domain name, a user would not only have to spoof the username, he : > would have to spoof the domain name too. At that point, you probably : > have bigger problems than access to your database. Also, in that : > situation, only the security token is going over the network, not your : : > password in clear text. The caveat is that you should be using the : > *domain name* as the prefix, not OPS$. : > : > -Original Message- : > Sent: Friday, June 20, 2003 6:20 AM : > To: Multiple recipients of list ORACLE-L : > : > : > Hi Arup, : > : > Remote OS authentication whether with OPS$ or not is still a risk. You : : > are intimating that SYSTEM is the only risky account involved here. : > What if any of the newly created OPS$ accounts have useful privileges. : : > I have seen a similar application to the one described recently. There : : > were forms within the application for administration and user : > management (in oracle, not the application) and the users who had : > access to these were assigned the DBA role and were of course external : : > accounts. : > : > I think what you should add to your comment is that the issue is : > overrated is that any OPS$ / external accounts should not have any : > dangerous privileges granted and certainly not DBA. If you can guess : > the name of an admin account even if its OPS$ then the issue is still : > severe. : > : > cheers : > : > Pete : > : > -- : > Pete Finnigan : > email:[EMAIL PROTECTED] : > Web site: http://www.petefinnigan.com - Oracle security audit : > specialists Book:Oracle security step-by-step Guide - see : > http://store.sans.org for details. : > : > -- : > Please see the official ORACLE-L FAQ: http://www.orafaq.net : > -- : > Author: Pete Finnigan : > INET: [EMAIL PROTECTED] : > : > Fat City Network Services-- 858-538-5051 http://www.fatcity.com : > San Diego, California-- Mailing list and web hosting services : > - : > To REMOVE yourself from this mailing list, send an E-Mail message : > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in : > the message BODY, include a line containing: UNSUB ORACLE-L (or the : > name of mailing list you want to be removed from). You may also send : > the HELP command for other information (like subscribing). : > -- : > Please see the official ORACLE-L FAQ: http://www.orafaq.net : > -- : > Author: Seefelt, Beth : > INET: [EMAIL PROTECTED] : > : > Fat City Network Services-- 858-538-5051 http://www.fatcity.com : > San Diego, California-- Mailing list and web hosting services : > - : > To REMOVE yourself from this mailing list, send an E-Mail message : > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in : > the message BODY, include a line containing: UNSUB ORACLE-L (or the : > name of mailing list you want to be removed from). You may also send : > the HELP command for other information (like
Re: oracle authentication from windows
Hello arup , I am using oracle 9.2.0.1.0 enterprise edition on windows xp my os_authent_prefix='' (I know , after reading your post , that its a security flaw ,but since this is just a test database on a single computer not on the network, let it be ) : Are you logging in the server through TPCIP? If you are logging in the : server directly you should be using IPC and then you can use the local : server logins. By the way what is your Oracle version (in full, e.g. 9.2, : not just 9i). I am logging in directly into the computer, not via telnet. I did the following create user administrator identified externally default tablespace users temporary tablespace temp quota unlimited on users ; grant create session , create table to administrator; now the winxp user is able to log into his schema ( after physically logging into this stand alone computer ) by using sqlplus /@service_name ONLY AS LONG AS I KEEP remote_os_authent=true other parameters : sqlnet_authentication_services=(none) remote_login_passwordfile=exclusive remote_os_roles=false As soon as I do the following : alter system set remote_os_authent=false scope=spfile; shutdown startup SQL> conn /@service_name ERROR: ORA-01004: default username feature not supported; logon denied Warning: You are no longer connected to ORACLE. but after setting remote_os_authen=true and bouncing the database SQL> conn /@service_name Connected. SQL> show user USER is "ADMINISTRATOR" SQL> That is the question which has me stumped. Any ideas ? Question number 2 : I have sqlnet_authentication_services=(none) Does this mean that Oracle is instructed to accept any external authentication or does it mean that Oracle is being instructed not to trust any external authentication ? I use sqlnet_authentication_services=(none) and am able to log in the winxp administrator ( as I show above) how did that work then ? Question number 3 : Assume that sqlnet_authentication_services=(none) . If there is an externally identified user called scott ( when os_authent_prefix='' ) or ops$scott (when os_authent_prefix='ops$' ) either which way suppose there is some user called X who is to identified externally , does this mean that anyone on the network can create an operating system user called X (after taking into account the value of op$_authent_prefix) log into their own computer using their own password and then log into the oracle schema of X ? or will that depend on the value of remote_os_authent. .. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: <[EMAIL PROTECTED] INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: oracle authentication from windows
Hi Pete, I don't think that's true about booting a PC with the same domain name that's not really part of the domain. Have you ever tried it? I'd be really interested if it works. I don't understand the part about booting into Linux and changing the username as its sent. Isn't the only username passed / ? Or are you talking about poking things at the packet level to make sqlnet think the user is domain authenticated. Cheers, Beth -Original Message- Sent: Friday, June 20, 2003 6:49 PM To: Multiple recipients of list ORACLE-L Hi Beth OK, I get your point but Arup was talking about automatic connections by setting remote_os_authent to true where you can either set the prefix to OPS$ or use identified externally. For these connections the user should not be prefixed by the domain name in the database. On the other hand using windows NT authentication and prefixing with the domain name can be spoofed by using a client that is not trusted such as windows 95 or 98 and setting the context to any domain you wish and adding the correct user. The other option is to insert a linux bootable CD and alter the username as it is sent. I agree with you that use of the domain method is better, BUT the point i was trying to make is still valid. That is to ensure that any external account observes the least privilege principle. cheers Pete In article <[EMAIL PROTECTED]>, Seefelt, Beth <[EMAIL PROTECTED]> writes > >I disagree. Remote OS authentication is not inherently insecure in >Windows like it is in Unix. If you prefix the account names with the >domain name, a user would not only have to spoof the username, he would >have to spoof the domain name too. At that point, you probably have >bigger problems than access to your database. Also, in that situation, >only the security token is going over the network, not your password in >clear text. The caveat is that you should be using the *domain name* >as the prefix, not OPS$. > >-Original Message- >Sent: Friday, June 20, 2003 6:20 AM >To: Multiple recipients of list ORACLE-L > > >Hi Arup, > >Remote OS authentication whether with OPS$ or not is still a risk. You >are intimating that SYSTEM is the only risky account involved here. >What if any of the newly created OPS$ accounts have useful privileges. >I have seen a similar application to the one described recently. There >were forms within the application for administration and user >management (in oracle, not the application) and the users who had >access to these were assigned the DBA role and were of course external >accounts. > >I think what you should add to your comment is that the issue is >overrated is that any OPS$ / external accounts should not have any >dangerous privileges granted and certainly not DBA. If you can guess >the name of an admin account even if its OPS$ then the issue is still >severe. > >cheers > >Pete > >-- >Pete Finnigan >email:[EMAIL PROTECTED] >Web site: http://www.petefinnigan.com - Oracle security audit >specialists >Book:Oracle security step-by-step Guide - see http://store.sans.org for >details. > >-- >Please see the official ORACLE-L FAQ: http://www.orafaq.net >-- >Author: Pete Finnigan > INET: [EMAIL PROTECTED] > >Fat City Network Services-- 858-538-5051 http://www.fatcity.com >San Diego, California-- Mailing list and web hosting services >- >To REMOVE yourself from this mailing list, send an E-Mail message >to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the >message BODY, include a line containing: UNSUB ORACLE-L (or the name of >mailing list you want to be removed from). You may also send the HELP >command for other information (like subscribing). >-- >Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Pete Finnigan email:[EMAIL PROTECTED] Web site: http://www.petefinnigan.com - Oracle security audit specialists Book:Oracle security step-by-step Guide - see http://store.sans.org for details. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Pete Finnigan INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Seefelt, Beth INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services -
RE: oracle authentication from windows
Because external authentication checks the domain name you are logged
into. You can't log into a local user JKILCHOE and connect to the
externally authenticated database user "MYDOMAIN\JKILCHOE".
Beth
-Original Message-
Sent: Friday, June 20, 2003 4:05 PM
To: Multiple recipients of list ORACLE-L
(my question follows)
> -Original Message-
> From: Seefelt, Beth [mailto:[EMAIL PROTECTED]
>
> I disagree. Remote OS authentication is not inherently insecure in
> Windows like it is in Unix. If you prefix the account names with the
> domain name, a user would not only have to spoof the username, he
> would have to spoof the domain name too. At that point, you probably
> have bigger problems than access to your database. Also, in that
> situation,
> only the security token is going over the network, not your
> password in
> clear text. The caveat is that you should be using the
> *domain name* as the prefix, not OPS$.
I don't understand how to accomplish this in practice. I currently sign
on to the Windows Network for domain MYDOMAIN with userid JKILCHOE. By
running the query suggested by Mr. Nanda I see that Oracle thinks my
username is jkilchoe:
SQL> select sys_context ('userenv', 'os_user') from dual
SYS_CONTEXT('USERENV','OS_USER')
-
jkilchoe
If I set
os_authent_prefix = MYDOMAIN
and create an Oracle username MYDOMAINJKILCHOE
how does that stop someone else from creating a local user JKILCHOE on
their machine, signing on to their local machine as JKILCHOE, and then
using SQL*Net to connect to the database as MYDOMAINJKILCHOE ?
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Jacques Kilchoer
INET: [EMAIL PROTECTED]
Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the
message BODY, include a line containing: UNSUB ORACLE-L (or the name of
mailing list you want to be removed from). You may also send the HELP
command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Seefelt, Beth
INET: [EMAIL PROTECTED]
Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
RE: oracle authentication from windows
No, that's not true. It actually uses your NT security token to validate that you are authenticated in the domain. You can't just give a rogue PC the same domain name, boot it up, and log into the database with external authentication. The PC would have to be a domain member, which means you have to have the domain admin password to join the domain, along with the users password so that you could log into the domain as them. The same is not true if you use another prefix such as OPS$. -Original Message- Sent: Friday, June 20, 2003 4:00 PM To: Multiple recipients of list ORACLE-L Beth, You are right in stating that OPS$ accounts are not inherently insecure. How is teh inclusion of domain name any more secure than using OPS$? Granted, the hacker has to guess the domain name in addition to user name, but so is using any other prefix other than OPS$. Besides if the users are not static, the domain names will be different. How will you address that issue? For instance, you domina name is MYCODOMAIN1 and your windows userid is mycodomain1\bseefelt, so the Oracle userid, as you propose should be "mydomain\bseeth". If you login to another domain, say, MYDOMAIN2, this account is no longer valid. So, I would say, mixing domains with username may not be a good idea, unless ofourse you have a single domain. Arup - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Friday, June 20, 2003 10:10 AM > > I disagree. Remote OS authentication is not inherently insecure in > Windows like it is in Unix. If you prefix the account names with the > domain name, a user would not only have to spoof the username, he > would have to spoof the domain name too. At that point, you probably > have bigger problems than access to your database. Also, in that > situation, only the security token is going over the network, not your > password in clear text. The caveat is that you should be using the > *domain name* as the prefix, not OPS$. > > -Original Message- > Sent: Friday, June 20, 2003 6:20 AM > To: Multiple recipients of list ORACLE-L > > > Hi Arup, > > Remote OS authentication whether with OPS$ or not is still a risk. You > are intimating that SYSTEM is the only risky account involved here. > What if any of the newly created OPS$ accounts have useful privileges. > I have seen a similar application to the one described recently. There > were forms within the application for administration and user > management (in oracle, not the application) and the users who had > access to these were assigned the DBA role and were of course external > accounts. > > I think what you should add to your comment is that the issue is > overrated is that any OPS$ / external accounts should not have any > dangerous privileges granted and certainly not DBA. If you can guess > the name of an admin account even if its OPS$ then the issue is still > severe. > > cheers > > Pete > > -- > Pete Finnigan > email:[EMAIL PROTECTED] > Web site: http://www.petefinnigan.com - Oracle security audit > specialists Book:Oracle security step-by-step Guide - see > http://store.sans.org for details. > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Pete Finnigan > INET: [EMAIL PROTECTED] > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > San Diego, California-- Mailing list and web hosting services > - > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L (or the > name of mailing list you want to be removed from). You may also send > the HELP command for other information (like subscribing). > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Seefelt, Beth > INET: [EMAIL PROTECTED] > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > San Diego, California-- Mailing list and web hosting services > - > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L (or the > name of mailing list you want to be removed from). You may also send > the HELP command for other information (like subscribing). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Arup Nanda INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru')
Re: oracle authentication from windows
Hi Arup, Thanks for the reply, I agree with you that ops$ accounts are definitely weaker than database authenticated accounts. I would always advocate trying to find another way to allow access if possible, i understand that in some cases remote authentication is what an organisation chooses to use because other options are not as useful to them. What i said in my first email still stands "least privilege principle" but if possible don't use external accounts and even less so remote external accounts, try to find another solution. BUT yes sometimes they have to be used and you are right to suggest a sound way to use them. cheers Pete In article <[EMAIL PROTECTED]>, Arup Nanda <[EMAIL PROTECTED]> writes >Hi Pete, > >I think you misunderstood. OPS$ accounts are weaker than the regular >accounts; but I maintain that they are not so insecure that they should be >outright banned. My position is they can be created if needed, but the >privileges should be granted judiciously, something that has to be done even >in regular accounts. OPS$ accounts with DBA privs - a big NO NO. -- Pete Finnigan email:[EMAIL PROTECTED] Web site: http://www.petefinnigan.com - Oracle security audit specialists Book:Oracle security step-by-step Guide - see http://store.sans.org for details. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Pete Finnigan INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: oracle authentication from windows
> : identified externally; a user named bulbul on the _server_ can login
> as
> : "sqlplus /", but a user named BULBUL on a remote machine will not be
> able
> : to.
> :
> : Hope this helps.
> :
> : Arup Nanda
> : www.proligence.com
> :
> : - Original Message -
> : To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
> : Sent: Saturday, June 21, 2003 2:19 AM
> :
> :
> : > Arup , the procedure you gave is correct and works fine.
> : > I tried it out on win32 with 9.2.0.1.0.
> : > But I had to set SQLNET.AUTHENTICATION_SERVICES= (none) in
> sqlnet.ora
> : > My fundamentals are really weak , so please forgive the stupid
> : > questions : These steps create a database user who will be
> : > authenticated by the operating system , right ? I assume that the
> : > authenticating os is the one which runs the database and not the
> os
> : > running on the remote client machine . If yes , then this would
> mean
> : > that all these externally identified users would have to somehow
> log
> : > onto the os of the database server.
> : >
> : >
> : > However why does this procedure work only when
> remote_os_authent=true
> : > ?
> : > I had posted this same question a while ago , did not get any
> : > satisfactory answers , though people told me that
> : > remote_os_authent=true is a security problem.
> : >
> : > But it doesn't seem to work without that.
> : > Any ideas of enabling "sqlplus /" without remote_os_authent=true ?
> : > Wouldn't remote_os_authent=true allow remote client machines to
> : > authenticate their users which can then log in to the database as
> : > long as they know the name of the externally authenticated
> username
> : > and value of os_authent_prefix
> : >
> : > - Original Message -
> : > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
> : > Sent: Friday, June 20, 2003 01:15
> : >
> : >
> : > Sure.
> : >
> : > Just declare these in your init.ora
> : >
> : > os_authent_prefix=OPS$
> : > remote_os_authent=TRUE
> : >
> : > bounce the database, add a user called OPS$,
> : > e.g. OPS$AK if your Windows login id is AK as
> : >
> : > create user ops$ak identified externally
> : >
> : > From windows connect as "/@servicename", e.g. sqlplus /@service1
> : >
> : > If it doesn't work, the OS user may be different. Use this query
> while
> : > connected to the database from Windows cleint.
> : >
> : > SQL> select sys_context('USERENV','OS_USER') from dual;
> : >
> : > See what OS username comes up; use that instead.
> : >
> : > HTH.
> : >
> : > Arup Nanda
> : > www.proligence.com
> : >
> : >
> : > - Original Message -
> : > From: AK
> : > To: Multiple recipients of list ORACLE-L
> : > Sent: Thursday, June 19, 2003 1:10 PM
> : > Subject: oracle authentication from windows
> : >
> : >
> : > We want our client users ( forms user ) to just enter windows
> : > password and then automatically able to get in to oracle .Is there
> a
> : > way oracle can authenticate from windows ( or active directory ) .
> : > enbadding password in runform.exe not an option .
> : >
> : > thanks,
> : > -ak
> :
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: <[EMAIL PROTECTED]
> INET: [EMAIL PROTECTED]
>
> Fat City Network Services-- 858-538-5051 http://www.fatcity.com
> San Diego, California-- Mailing list and web hosting services
> -
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Arup Nanda
INET: [EMAIL PROTECTED]
Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Re: oracle authentication from windows
Thank you very much Arup , very lucid and detailed explanation.
In the last point you said :
:3) If remote_os_authent is false, but the database has a user
OPS$BULBUL
: identified externally; a user named bulbul on the _server_ can login
as
: "sqlplus /", but a user named BULBUL on a remote machine will not be
able
: to.
That is the problem , as I said I am not able to log in even the
database server's operating system users ( who are identified
externally ) unless I set remote_os_authent= true ; But then as you
said any remote client could authenticate the externally identified
user in whatever means, and then they could log in. I mean
create user scott identified externally;
grant create session to scott ;
If on the client machine there is an operating system user called
scott, then he can log in to the scott schema.
Any ideas how to restrict the externally identified users so that they
have to log in to the database server to access their oracle schemas.?
Another doubt is from what you said about
sqlnet_authentication_services :
: You are using (none) because you do not want to rely on the
authentication
: service provided by others.
:
So this means that the database will not recognise the authentication
done by some other means ( like the white house guards refusing to
recognize the authentication provided by the people on the hill).
Then how will someone log in if he is identified externally ?
Once again thanks for the excellent response, thanks for taking time
out to explain the physical significance of these parameters in a very
nice way.
: (2) remote_os_authent means the user is authenticated in whatever
manner in
: the _client_ operating system, not the server. The user may have no
account
: with the server.
:
: (3) If remote_os_authent is false, but the database has a user
OPS$BULBUL
: identified externally; a user named bulbul on the _server_ can login
as
: "sqlplus /", but a user named BULBUL on a remote machine will not be
able
: to.
:
: Hope this helps.
:
: Arup Nanda
: www.proligence.com
:
: - Original Message -
: To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
: Sent: Saturday, June 21, 2003 2:19 AM
:
:
: > Arup , the procedure you gave is correct and works fine.
: > I tried it out on win32 with 9.2.0.1.0.
: > But I had to set SQLNET.AUTHENTICATION_SERVICES= (none) in
sqlnet.ora
: > My fundamentals are really weak , so please forgive the stupid
: > questions : These steps create a database user who will be
: > authenticated by the operating system , right ? I assume that the
: > authenticating os is the one which runs the database and not the
os
: > running on the remote client machine . If yes , then this would
mean
: > that all these externally identified users would have to somehow
log
: > onto the os of the database server.
: >
: >
: > However why does this procedure work only when
remote_os_authent=true
: > ?
: > I had posted this same question a while ago , did not get any
: > satisfactory answers , though people told me that
: > remote_os_authent=true is a security problem.
: >
: > But it doesn't seem to work without that.
: > Any ideas of enabling "sqlplus /" without remote_os_authent=true ?
: > Wouldn't remote_os_authent=true allow remote client machines to
: > authenticate their users which can then log in to the database as
: > long as they know the name of the externally authenticated
username
: > and value of os_authent_prefix
: >
: > - Original Message -
: > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
: > Sent: Friday, June 20, 2003 01:15
: >
: >
: > Sure.
: >
: > Just declare these in your init.ora
: >
: > os_authent_prefix=OPS$
: > remote_os_authent=TRUE
: >
: > bounce the database, add a user called OPS$,
: > e.g. OPS$AK if your Windows login id is AK as
: >
: > create user ops$ak identified externally
: >
: > From windows connect as "/@servicename", e.g. sqlplus /@service1
: >
: > If it doesn't work, the OS user may be different. Use this query
while
: > connected to the database from Windows cleint.
: >
: > SQL> select sys_context('USERENV','OS_USER') from dual;
: >
: > See what OS username comes up; use that instead.
: >
: > HTH.
: >
: > Arup Nanda
: > www.proligence.com
: >
: >
: > - Original Message -
: > From: AK
: > To: Multiple recipients of list ORACLE-L
: > Sent: Thursday, June 19, 2003 1:10 PM
: > Subject: oracle authentication from windows
: >
: >
: > We want our client users ( forms user ) to just enter windows
: > password and then automatically able to get in to oracle .Is there
a
: > way oracle can authenticate from windows ( or active directory ) .
: > enba
Re: oracle authentication from windows
OPS$ accounts are, basically, Oracle's attempt to implement single sign-on. OPS$ accounts are not a problem, as long as there is no network involved because your oracle database is as secure as the underlying OS. You can not have more security. When there is a network involved, everthing is OK as long as one can totally control it. In other words, no nodes should be addedd to the network without a knowledge of the DBA. In the era of laptops when anybody can walk in and plug his laptop in a departmental ethernet segment, this cannot be controlled. If you add V internet to the equation, situation becomes even worse. Single sign-on, on the other hand is not insecure, as long as it is done properly. There are many single-sign on methods (Kerberos, RADIUS are the first ones that come to mind) but they all cost money and are usable only with the advanced security option. Biometrics doesn't yet instill any confidence in me. Fingerprints (the so called Yakuza method) are not so easy distinguish among as one would think. On 2003.06.21 12:04, Arup Nanda wrote: Hi Pete, I think you misunderstood. OPS$ accounts are weaker than the regular accounts; but I maintain that they are not so insecure that they should be outright banned. My position is they can be created if needed, but the privileges should be granted judiciously, something that has to be done even in regular accounts. OPS$ accounts with DBA privs - a big NO NO. About the project you mentioned where the user admins are not really DBAs but regular users who create or manage users via Forms - why not create a procedure under user sys to manage all that and give execute privs to the users, instead of giving them sweeping privs like DBA? That way your OPS$ accounts are limited to the operations performed by this procedure, but not anything else. HTH. Arup - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Saturday, June 21, 2003 5:08 AM > Hi Arup, > > The example was an application i saw recently, the administration was > application administration via a form that included adding and > maintaining Oracle users. The people who used it were not DBA's but > their users had been granted the DBA role. > > I think we will have to agree to disagree though that external accounts > are always going to be weaker than ones with database authentication > (weak passwords I agree make those easy as well) simply because they > rely on another system to do the authentication for them and those > systems have to be trusted. > > cheers > > Pete > > In article <[EMAIL PROTECTED]>, Arup Nanda > <[EMAIL PROTECTED]> writes > >Pete, > > > >Apprciate your comments. You are right in stating that if the OPS$ accounts > >have special privs they might be abused. But how it is any different than > >any other user id with special privileges whose password is not guarded > >well? The security hole does not come from the fact that remote_os_authent > >is true, but due to lax security management. Removing OPS$ accounts will not > >help increase the security any more than simply evaluating who has what > >privileges. > > > >Instead of fighting the introduction of ops$ accounts, what I suggested was > >to have a safe practice of setting a prefix. Of course, the privileges of > >such accounts should be carefully monitored and accesses should be provided > >to the bare minimum; dba accounts are certainly a big no. In your example > >you specified, this is rather ridiculous to have a form for a dba user. Why > >not use OEM, for free? > > > >In my book I have addressed some of these issues and common misconceptions > >and tried to separate myths from facts. > > > >Thanks. > > > >Arup > > > > > > > >- Original Message - > >To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > >Sent: Friday, June 20, 2003 6:19 AM > > > > > >> Hi Arup, > >> > >> Remote OS authentication whether with OPS$ or not is still a risk. You > >> are intimating that SYSTEM is the only risky account involved here. What > >> if any of the newly created OPS$ accounts have useful privileges. I have > >> seen a similar application to the one described recently. There were > >> forms within the application for administration and user management (in > >> oracle, not the application) and the users who had access to these were > >> assigned the DBA role and were of course external accounts. > >> > >> I think what you should add to your comment is that the issue is > >> overrated is that any OPS$ / external accounts should not have any > >> dangerous privileges granted and certainly not DBA. If you can guess the > >> name of an admin account even if its OPS$ then the issue is still > >> severe. > >> > >> cheers > >> > >> Pete > >> > >> -- > >> Pete Finnigan > >> email:[EMAIL PROTECTED] > >> Web site: http://www.petefinnigan.com - Oracle security audit specialists > >> Book:Oracle security step-by-step Guide - see http://store.sans.org for > >details. > >> > >>
Re: oracle authentication from windows
Hi Pete, I think you misunderstood. OPS$ accounts are weaker than the regular accounts; but I maintain that they are not so insecure that they should be outright banned. My position is they can be created if needed, but the privileges should be granted judiciously, something that has to be done even in regular accounts. OPS$ accounts with DBA privs - a big NO NO. About the project you mentioned where the user admins are not really DBAs but regular users who create or manage users via Forms - why not create a procedure under user sys to manage all that and give execute privs to the users, instead of giving them sweeping privs like DBA? That way your OPS$ accounts are limited to the operations performed by this procedure, but not anything else. HTH. Arup - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Saturday, June 21, 2003 5:08 AM > Hi Arup, > > The example was an application i saw recently, the administration was > application administration via a form that included adding and > maintaining Oracle users. The people who used it were not DBA's but > their users had been granted the DBA role. > > I think we will have to agree to disagree though that external accounts > are always going to be weaker than ones with database authentication > (weak passwords I agree make those easy as well) simply because they > rely on another system to do the authentication for them and those > systems have to be trusted. > > cheers > > Pete > > In article <[EMAIL PROTECTED]>, Arup Nanda > <[EMAIL PROTECTED]> writes > >Pete, > > > >Apprciate your comments. You are right in stating that if the OPS$ accounts > >have special privs they might be abused. But how it is any different than > >any other user id with special privileges whose password is not guarded > >well? The security hole does not come from the fact that remote_os_authent > >is true, but due to lax security management. Removing OPS$ accounts will not > >help increase the security any more than simply evaluating who has what > >privileges. > > > >Instead of fighting the introduction of ops$ accounts, what I suggested was > >to have a safe practice of setting a prefix. Of course, the privileges of > >such accounts should be carefully monitored and accesses should be provided > >to the bare minimum; dba accounts are certainly a big no. In your example > >you specified, this is rather ridiculous to have a form for a dba user. Why > >not use OEM, for free? > > > >In my book I have addressed some of these issues and common misconceptions > >and tried to separate myths from facts. > > > >Thanks. > > > >Arup > > > > > > > >- Original Message - > >To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > >Sent: Friday, June 20, 2003 6:19 AM > > > > > >> Hi Arup, > >> > >> Remote OS authentication whether with OPS$ or not is still a risk. You > >> are intimating that SYSTEM is the only risky account involved here. What > >> if any of the newly created OPS$ accounts have useful privileges. I have > >> seen a similar application to the one described recently. There were > >> forms within the application for administration and user management (in > >> oracle, not the application) and the users who had access to these were > >> assigned the DBA role and were of course external accounts. > >> > >> I think what you should add to your comment is that the issue is > >> overrated is that any OPS$ / external accounts should not have any > >> dangerous privileges granted and certainly not DBA. If you can guess the > >> name of an admin account even if its OPS$ then the issue is still > >> severe. > >> > >> cheers > >> > >> Pete > >> > >> -- > >> Pete Finnigan > >> email:[EMAIL PROTECTED] > >> Web site: http://www.petefinnigan.com - Oracle security audit specialists > >> Book:Oracle security step-by-step Guide - see http://store.sans.org for > >details. > >> > >> -- > >> Please see the official ORACLE-L FAQ: http://www.orafaq.net > >> -- > >> Author: Pete Finnigan > >> INET: [EMAIL PROTECTED] > >> > >> Fat City Network Services-- 858-538-5051 http://www.fatcity.com > >> San Diego, California-- Mailing list and web hosting services > >> - > >> To REMOVE yourself from this mailing list, send an E-Mail message > >> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > >> the message BODY, include a line containing: UNSUB ORACLE-L > >> (or the name of mailing list you want to be removed from). You may > >> also send the HELP command for other information (like subscribing). > >> > >-- > >Please see the official ORACLE-L FAQ: http://www.orafaq.net > > -- > Pete Finnigan > email:[EMAIL PROTECTED] > Web site: http://www.petefinnigan.com - Oracle security audit specialists > Book:Oracle security step-by-step Guide - see http://store.sans.org for details. > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- >
Re: oracle authentication from windows
Bulbul,
Your question can be broken up into basically three parts.
(1) Setting SQLNET.AUTHENTICATION_SERVICES is used for authenticating users
for single sign-on applications. For instance, you are using kerberos
authentication method and using Oracle Adanced Networking Option. Anyone
authenticated to the OS has already passed the test by Kerberos, and you
decide to let the person in without further authentication by Oracle (i.e.
userid, password). In this case, you would set
SQLNET.AUTHENTICATION_SERVICES= (kerberos5). Imagine you are visiting the
White House after visiting US Capitol. At the Capitol, they checked you out
and made sure you are indeed Bulbul; i other words you are who you claim to
be - a process we refer to as authentication. Now suppose you were escorteed
to White Huose in a Secret Service van sorroeunded by a dozen agents. At the
White House, the gurards may decided to let you enter without further
authentication. Why? Becuase they know the authentication done at Capitol
was rigorous enough and can be trusted. This is similar to a user
authenticated by Kerberos and Oracle assumes that the proces is reliable
anough to let the user in.
You are using (none) because you do not want to rely on the authentication
service provided by others.
(2) remote_os_authent means the user is authenticated in whatever manner in
the _client_ operating system, not the server. The user may have no account
with the server.
(3) If remote_os_authent is false, but the database has a user OPS$BULBUL
identified externally; a user named bulbul on the _server_ can login as
"sqlplus /", but a user named BULBUL on a remote machine will not be able
to.
Hope this helps.
Arup Nanda
www.proligence.com
- Original Message -
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Saturday, June 21, 2003 2:19 AM
> Arup , the procedure you gave is correct and works fine.
> I tried it out on win32 with 9.2.0.1.0.
> But I had to set SQLNET.AUTHENTICATION_SERVICES= (none) in sqlnet.ora
> My fundamentals are really weak , so please forgive the stupid
> questions : These steps create a database user who will be
> authenticated by the operating system , right ? I assume that the
> authenticating os is the one which runs the database and not the os
> running on the remote client machine . If yes , then this would mean
> that all these externally identified users would have to somehow log
> onto the os of the database server.
>
>
> However why does this procedure work only when remote_os_authent=true
> ?
> I had posted this same question a while ago , did not get any
> satisfactory answers , though people told me that
> remote_os_authent=true is a security problem.
>
> But it doesn't seem to work without that.
> Any ideas of enabling "sqlplus /" without remote_os_authent=true ?
> Wouldn't remote_os_authent=true allow remote client machines to
> authenticate their users which can then log in to the database as
> long as they know the name of the externally authenticated username
> and value of os_authent_prefix
>
> - Original Message -
> To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
> Sent: Friday, June 20, 2003 01:15
>
>
> Sure.
>
> Just declare these in your init.ora
>
> os_authent_prefix=OPS$
> remote_os_authent=TRUE
>
> bounce the database, add a user called OPS$,
> e.g. OPS$AK if your Windows login id is AK as
>
> create user ops$ak identified externally
>
> From windows connect as "/@servicename", e.g. sqlplus /@service1
>
> If it doesn't work, the OS user may be different. Use this query while
> connected to the database from Windows cleint.
>
> SQL> select sys_context('USERENV','OS_USER') from dual;
>
> See what OS username comes up; use that instead.
>
> HTH.
>
> Arup Nanda
> www.proligence.com
>
>
> - Original Message -
> From: AK
> To: Multiple recipients of list ORACLE-L
> Sent: Thursday, June 19, 2003 1:10 PM
> Subject: oracle authentication from windows
>
>
> We want our client users ( forms user ) to just enter windows
> password and then automatically able to get in to oracle .Is there a
> way oracle can authenticate from windows ( or active directory ) .
> enbadding password in runform.exe not an option .
>
> thanks,
> -ak
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: <[EMAIL PROTECTED]
> INET: [EMAIL PROTECTED]
>
> Fat City Network Services-- 858-538-5051 http://www.fatcity.com
> San Diego, California-- Mailing list and web hosting services
> -
> To REMOVE yourself from this
Re: oracle authentication from windows
Hi Arup, The example was an application i saw recently, the administration was application administration via a form that included adding and maintaining Oracle users. The people who used it were not DBA's but their users had been granted the DBA role. I think we will have to agree to disagree though that external accounts are always going to be weaker than ones with database authentication (weak passwords I agree make those easy as well) simply because they rely on another system to do the authentication for them and those systems have to be trusted. cheers Pete In article <[EMAIL PROTECTED]>, Arup Nanda <[EMAIL PROTECTED]> writes >Pete, > >Apprciate your comments. You are right in stating that if the OPS$ accounts >have special privs they might be abused. But how it is any different than >any other user id with special privileges whose password is not guarded >well? The security hole does not come from the fact that remote_os_authent >is true, but due to lax security management. Removing OPS$ accounts will not >help increase the security any more than simply evaluating who has what >privileges. > >Instead of fighting the introduction of ops$ accounts, what I suggested was >to have a safe practice of setting a prefix. Of course, the privileges of >such accounts should be carefully monitored and accesses should be provided >to the bare minimum; dba accounts are certainly a big no. In your example >you specified, this is rather ridiculous to have a form for a dba user. Why >not use OEM, for free? > >In my book I have addressed some of these issues and common misconceptions >and tried to separate myths from facts. > >Thanks. > >Arup > > > >- Original Message - >To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> >Sent: Friday, June 20, 2003 6:19 AM > > >> Hi Arup, >> >> Remote OS authentication whether with OPS$ or not is still a risk. You >> are intimating that SYSTEM is the only risky account involved here. What >> if any of the newly created OPS$ accounts have useful privileges. I have >> seen a similar application to the one described recently. There were >> forms within the application for administration and user management (in >> oracle, not the application) and the users who had access to these were >> assigned the DBA role and were of course external accounts. >> >> I think what you should add to your comment is that the issue is >> overrated is that any OPS$ / external accounts should not have any >> dangerous privileges granted and certainly not DBA. If you can guess the >> name of an admin account even if its OPS$ then the issue is still >> severe. >> >> cheers >> >> Pete >> >> -- >> Pete Finnigan >> email:[EMAIL PROTECTED] >> Web site: http://www.petefinnigan.com - Oracle security audit specialists >> Book:Oracle security step-by-step Guide - see http://store.sans.org for >details. >> >> -- >> Please see the official ORACLE-L FAQ: http://www.orafaq.net >> -- >> Author: Pete Finnigan >> INET: [EMAIL PROTECTED] >> >> Fat City Network Services-- 858-538-5051 http://www.fatcity.com >> San Diego, California-- Mailing list and web hosting services >> - >> To REMOVE yourself from this mailing list, send an E-Mail message >> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in >> the message BODY, include a line containing: UNSUB ORACLE-L >> (or the name of mailing list you want to be removed from). You may >> also send the HELP command for other information (like subscribing). >> >-- >Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Pete Finnigan email:[EMAIL PROTECTED] Web site: http://www.petefinnigan.com - Oracle security audit specialists Book:Oracle security step-by-step Guide - see http://store.sans.org for details. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Pete Finnigan INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: oracle authentication from windows
Arup , the procedure you gave is correct and works fine.
I tried it out on win32 with 9.2.0.1.0.
But I had to set SQLNET.AUTHENTICATION_SERVICES= (none) in sqlnet.ora
My fundamentals are really weak , so please forgive the stupid
questions : These steps create a database user who will be
authenticated by the operating system , right ? I assume that the
authenticating os is the one which runs the database and not the os
running on the remote client machine . If yes , then this would mean
that all these externally identified users would have to somehow log
onto the os of the database server.
However why does this procedure work only when remote_os_authent=true
?
I had posted this same question a while ago , did not get any
satisfactory answers , though people told me that
remote_os_authent=true is a security problem.
But it doesn't seem to work without that.
Any ideas of enabling "sqlplus /" without remote_os_authent=true ?
Wouldn't remote_os_authent=true allow remote client machines to
authenticate their users which can then log in to the database as
long as they know the name of the externally authenticated username
and value of os_authent_prefix
- Original Message -
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Friday, June 20, 2003 01:15
Sure.
Just declare these in your init.ora
os_authent_prefix=OPS$
remote_os_authent=TRUE
bounce the database, add a user called OPS$,
e.g. OPS$AK if your Windows login id is AK as
create user ops$ak identified externally
>From windows connect as "/@servicename", e.g. sqlplus /@service1
If it doesn't work, the OS user may be different. Use this query while
connected to the database from Windows cleint.
SQL> select sys_context('USERENV','OS_USER') from dual;
See what OS username comes up; use that instead.
HTH.
Arup Nanda
www.proligence.com
- Original Message -
From: AK
To: Multiple recipients of list ORACLE-L
Sent: Thursday, June 19, 2003 1:10 PM
Subject: oracle authentication from windows
We want our client users ( forms user ) to just enter windows
password and then automatically able to get in to oracle .Is there a
way oracle can authenticate from windows ( or active directory ) .
enbadding password in runform.exe not an option .
thanks,
-ak
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: <[EMAIL PROTECTED]
INET: [EMAIL PROTECTED]
Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Re: oracle authentication from windows
Hi Beth OK, I get your point but Arup was talking about automatic connections by setting remote_os_authent to true where you can either set the prefix to OPS$ or use identified externally. For these connections the user should not be prefixed by the domain name in the database. On the other hand using windows NT authentication and prefixing with the domain name can be spoofed by using a client that is not trusted such as windows 95 or 98 and setting the context to any domain you wish and adding the correct user. The other option is to insert a linux bootable CD and alter the username as it is sent. I agree with you that use of the domain method is better, BUT the point i was trying to make is still valid. That is to ensure that any external account observes the least privilege principle. cheers Pete In article <[EMAIL PROTECTED]>, Seefelt, Beth <[EMAIL PROTECTED]> writes > >I disagree. Remote OS authentication is not inherently insecure in >Windows like it is in Unix. If you prefix the account names with the >domain name, a user would not only have to spoof the username, he would >have to spoof the domain name too. At that point, you probably have >bigger problems than access to your database. Also, in that situation, >only the security token is going over the network, not your password in >clear text. The caveat is that you should be using the *domain name* as >the prefix, not OPS$. > >-Original Message- >Sent: Friday, June 20, 2003 6:20 AM >To: Multiple recipients of list ORACLE-L > > >Hi Arup, > >Remote OS authentication whether with OPS$ or not is still a risk. You >are intimating that SYSTEM is the only risky account involved here. What >if any of the newly created OPS$ accounts have useful privileges. I have >seen a similar application to the one described recently. There were >forms within the application for administration and user management (in >oracle, not the application) and the users who had access to these were >assigned the DBA role and were of course external accounts. > >I think what you should add to your comment is that the issue is >overrated is that any OPS$ / external accounts should not have any >dangerous privileges granted and certainly not DBA. If you can guess the >name of an admin account even if its OPS$ then the issue is still >severe. > >cheers > >Pete > >-- >Pete Finnigan >email:[EMAIL PROTECTED] >Web site: http://www.petefinnigan.com - Oracle security audit >specialists >Book:Oracle security step-by-step Guide - see http://store.sans.org for >details. > >-- >Please see the official ORACLE-L FAQ: http://www.orafaq.net >-- >Author: Pete Finnigan > INET: [EMAIL PROTECTED] > >Fat City Network Services-- 858-538-5051 http://www.fatcity.com >San Diego, California-- Mailing list and web hosting services >- >To REMOVE yourself from this mailing list, send an E-Mail message >to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in >the message BODY, include a line containing: UNSUB ORACLE-L >(or the name of mailing list you want to be removed from). You may >also send the HELP command for other information (like subscribing). >-- >Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Pete Finnigan email:[EMAIL PROTECTED] Web site: http://www.petefinnigan.com - Oracle security audit specialists Book:Oracle security step-by-step Guide - see http://store.sans.org for details. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Pete Finnigan INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: oracle authentication from windows
All, Oracle has rounded all this discussion up in Note:207959.1 'All About Security: User, Privilege, Role, SYSDBA, O/S Authentication, Audit, Encryption, OLS' which is a jump off point to *lots* of other Notes. John > -Original Message- > From: Arup Nanda [mailto:[EMAIL PROTECTED] > Sent: Friday, June 20, 2003 12:16 PM > To: Multiple recipients of list ORACLE-L > Subject: Re: oracle authentication from windows > > > Pete, > > Apprciate your comments. You are right in stating that if the > OPS$ accounts > have special privs they might be abused. But how it is any > different than > any other user id with special privileges whose password is > not guarded > well? The security hole does not come from the fact that > remote_os_authent > is true, but due to lax security management. Removing OPS$ > accounts will not > help increase the security any more than simply evaluating > who has what > privileges. > > Instead of fighting the introduction of ops$ accounts, what I > suggested was > to have a safe practice of setting a prefix. Of course, the > privileges of > such accounts should be carefully monitored and accesses > should be provided > to the bare minimum; dba accounts are certainly a big no. In > your example > you specified, this is rather ridiculous to have a form for a > dba user. Why > not use OEM, for free? > > In my book I have addressed some of these issues and common > misconceptions > and tried to separate myths from facts. > > Thanks. > > Arup > > > > - Original Message - > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > Sent: Friday, June 20, 2003 6:19 AM > > > > Hi Arup, > > > > Remote OS authentication whether with OPS$ or not is still > a risk. You > > are intimating that SYSTEM is the only risky account > involved here. What > > if any of the newly created OPS$ accounts have useful > privileges. I have > > seen a similar application to the one described recently. There were > > forms within the application for administration and user > management (in > > oracle, not the application) and the users who had access > to these were > > assigned the DBA role and were of course external accounts. > > > > I think what you should add to your comment is that the issue is > > overrated is that any OPS$ / external accounts should not have any > > dangerous privileges granted and certainly not DBA. If you > can guess the > > name of an admin account even if its OPS$ then the issue is still > > severe. > > > > cheers > > > > Pete > > > > -- > > Pete Finnigan > > email:[EMAIL PROTECTED] > > Web site: http://www.petefinnigan.com - Oracle security > audit specialists > > Book:Oracle security step-by-step Guide - see http://store.sans.org for details. > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Pete Finnigan > INET: [EMAIL PROTECTED] > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > San Diego, California-- Mailing list and web hosting services > - > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Arup Nanda INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: John Kanagaraj INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: oracle authentication from windows
Beth, You are right in stating that OPS$ accounts are not inherently insecure. How is teh inclusion of domain name any more secure than using OPS$? Granted, the hacker has to guess the domain name in addition to user name, but so is using any other prefix other than OPS$. Besides if the users are not static, the domain names will be different. How will you address that issue? For instance, you domina name is MYCODOMAIN1 and your windows userid is mycodomain1\bseefelt, so the Oracle userid, as you propose should be "mydomain\bseeth". If you login to another domain, say, MYDOMAIN2, this account is no longer valid. So, I would say, mixing domains with username may not be a good idea, unless ofourse you have a single domain. Arup - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Friday, June 20, 2003 10:10 AM > > I disagree. Remote OS authentication is not inherently insecure in > Windows like it is in Unix. If you prefix the account names with the > domain name, a user would not only have to spoof the username, he would > have to spoof the domain name too. At that point, you probably have > bigger problems than access to your database. Also, in that situation, > only the security token is going over the network, not your password in > clear text. The caveat is that you should be using the *domain name* as > the prefix, not OPS$. > > -Original Message- > Sent: Friday, June 20, 2003 6:20 AM > To: Multiple recipients of list ORACLE-L > > > Hi Arup, > > Remote OS authentication whether with OPS$ or not is still a risk. You > are intimating that SYSTEM is the only risky account involved here. What > if any of the newly created OPS$ accounts have useful privileges. I have > seen a similar application to the one described recently. There were > forms within the application for administration and user management (in > oracle, not the application) and the users who had access to these were > assigned the DBA role and were of course external accounts. > > I think what you should add to your comment is that the issue is > overrated is that any OPS$ / external accounts should not have any > dangerous privileges granted and certainly not DBA. If you can guess the > name of an admin account even if its OPS$ then the issue is still > severe. > > cheers > > Pete > > -- > Pete Finnigan > email:[EMAIL PROTECTED] > Web site: http://www.petefinnigan.com - Oracle security audit > specialists > Book:Oracle security step-by-step Guide - see http://store.sans.org for > details. > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Pete Finnigan > INET: [EMAIL PROTECTED] > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > San Diego, California-- Mailing list and web hosting services > - > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Seefelt, Beth > INET: [EMAIL PROTECTED] > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > San Diego, California-- Mailing list and web hosting services > - > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Arup Nanda INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: oracle authentication from windows
(my question follows)
> -Original Message-
> From: Seefelt, Beth [mailto:[EMAIL PROTECTED]
>
> I disagree. Remote OS authentication is not inherently insecure in
> Windows like it is in Unix. If you prefix the account names with the
> domain name, a user would not only have to spoof the
> username, he would
> have to spoof the domain name too. At that point, you probably have
> bigger problems than access to your database. Also, in that
> situation,
> only the security token is going over the network, not your
> password in
> clear text. The caveat is that you should be using the
> *domain name* as the prefix, not OPS$.
I don't understand how to accomplish this in practice. I currently sign on to the
Windows Network for domain MYDOMAIN with userid JKILCHOE. By running the query
suggested by Mr. Nanda I see that Oracle thinks my username is jkilchoe:
SQL> select sys_context ('userenv', 'os_user') from dual
SYS_CONTEXT('USERENV','OS_USER')
-
jkilchoe
If I set
os_authent_prefix = MYDOMAIN
and create an Oracle username MYDOMAINJKILCHOE
how does that stop someone else from creating a local user JKILCHOE on their machine,
signing on to their local machine as JKILCHOE, and then using SQL*Net to connect to
the database as MYDOMAINJKILCHOE ?
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Jacques Kilchoer
INET: [EMAIL PROTECTED]
Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Re: oracle authentication from windows
David,
I do feel your pain. Sometimes the auditors just go overboard looking over
some set checklist and some items in their checklist just plain contradict
each other. Take example I just went through recently.
I am making the databases of a few healthcare companies HIPAA compliant. A
recent audit made this point: "The software owner account should be locked
and be opened after a written memo to the sys admin. The fact that oracle
account is not locked is a huge security hole". All right, that meant my
oracle account is now locked. Jeez! Well, how do I start and stop the
database? Auditor: "the starting and stopping of the database has to be done
from Oracle Enterprise Manager console, connected as SYSDBA". And, that is
supposed to be more secure??!
The point is, don't just assume that the auditors know the best. Some of the
points could be good independently, for instance, in the above case, they
are. But taken together they may not be practical. Of course, pick you
battles. If they want to get rid of OPS$ accounts, let the developers fight
over it; they will be most affected - passing user ids and passwords, etc.
But in their zeal to seal the deal, make sure they are not hardcoding
passwords in the applications, a common problem.
HTH.
Arup Nanda
www.proligence.com
- Original Message -
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Friday, June 20, 2003 9:44 AM
> This is an interesting one. I am currently going through (tortured)
another
> system audit. One of the many questions the auditors (I am being attacked
> from all sides) had about the Oracle configuration was "Can remote
> authenticated network users connect to the database?".
>
> If auditors know this is a weakness, maybe it would be a good idea to
avoid
> its use.
>
> btw I do use O/S authenticated userids but remote authentication has been
> disabled (deliberately). We are running Oracle on Unix so our batch jobs
use
> O/S authenticated ids.
>
>
> >From: "Gogala, Mladen" <[EMAIL PROTECTED]>
> >Reply-To: [EMAIL PROTECTED]
> >To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
> >Subject: RE: oracle authentication from windows
> >Date: Thu, 19 Jun 2003 12:19:59 -0800
> >
> >That, of course, will render your database totally insecure and open to
> >anybody
> >who can bring in a WinXP laptop, change the windoze username and log in
as
> >he pleases.
> >DBA that sets his production parameters the way Arup described deserves
to
> >be
> >publicly tortured by Bill O'Reilly in the "no spin zone".
> >
> >
> >Mladen Gogala
> >Oracle DBA
> >Phone:(203) 459-6855
> >Email:[EMAIL PROTECTED]
> >
> >-Original Message-
> >Sent: Thursday, June 19, 2003 3:46 PM
> >To: Multiple recipients of list ORACLE-L
> >
> >
> >Sure.
> >
> >Just declare these in your init.ora
> >
> >os_authent_prefix=OPS$
> >remote_os_authent=TRUE
> >
> >bounce the database, add a user called OPS$, e.g.
> >OPS$AK if your Windows login id is AK as
> >
> >create user ops$ak identified externally
> >
> >From windows connect as "/@servicename", e.g. sqlplus /@service1
> >
> >If it doesn't work, the OS user may be different. Use this query while
> >connected to the database from Windows cleint.
> >
> >SQL> select sys_context('USERENV','OS_USER') from dual;
> >
> >See what OS username comes up; use that instead.
> >
> >HTH.
> >
> >Arup Nanda
> >www.proligence.com
> >
> >
> >
> >- Original Message -
> >To: Multiple <mailto:[EMAIL PROTECTED]> recipients of list ORACLE-L
> >Sent: Thursday, June 19, 2003 1:10 PM
> >
> >We want our client users ( forms user ) to just enter windows password
and
> >then automatically able to get in to oracle .Is there a way oracle can
> >authenticate from windows ( or active directory ) . enbadding password in
> >runform.exe not an option .
> >
> >thanks,
> >-ak
> >
>
> _
> Help STOP SPAM with the new MSN 8 and get 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: david davis
> INET: [EMAIL PROTECTED]
>
> Fat City Network Services-- 858-538-5051 http://www.fatcity.com
> San Diego, California-- Mailing list and web hosting services
> --
Re: oracle authentication from windows
Pete, Apprciate your comments. You are right in stating that if the OPS$ accounts have special privs they might be abused. But how it is any different than any other user id with special privileges whose password is not guarded well? The security hole does not come from the fact that remote_os_authent is true, but due to lax security management. Removing OPS$ accounts will not help increase the security any more than simply evaluating who has what privileges. Instead of fighting the introduction of ops$ accounts, what I suggested was to have a safe practice of setting a prefix. Of course, the privileges of such accounts should be carefully monitored and accesses should be provided to the bare minimum; dba accounts are certainly a big no. In your example you specified, this is rather ridiculous to have a form for a dba user. Why not use OEM, for free? In my book I have addressed some of these issues and common misconceptions and tried to separate myths from facts. Thanks. Arup - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Friday, June 20, 2003 6:19 AM > Hi Arup, > > Remote OS authentication whether with OPS$ or not is still a risk. You > are intimating that SYSTEM is the only risky account involved here. What > if any of the newly created OPS$ accounts have useful privileges. I have > seen a similar application to the one described recently. There were > forms within the application for administration and user management (in > oracle, not the application) and the users who had access to these were > assigned the DBA role and were of course external accounts. > > I think what you should add to your comment is that the issue is > overrated is that any OPS$ / external accounts should not have any > dangerous privileges granted and certainly not DBA. If you can guess the > name of an admin account even if its OPS$ then the issue is still > severe. > > cheers > > Pete > > -- > Pete Finnigan > email:[EMAIL PROTECTED] > Web site: http://www.petefinnigan.com - Oracle security audit specialists > Book:Oracle security step-by-step Guide - see http://store.sans.org for details. > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Pete Finnigan > INET: [EMAIL PROTECTED] > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > San Diego, California-- Mailing list and web hosting services > - > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Arup Nanda INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: oracle authentication from windows
- Original Message -
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Friday, June 20, 2003 9:44 AM
> This is an interesting one. I am currently going through (tortured)
another
> system audit. One of the many questions the auditors (I am being attacked
> from all sides) had about the Oracle configuration was "Can remote
> authenticated network users connect to the database?".
>
> If auditors know this is a weakness, maybe it would be a good idea to
avoid
> its use.
>
> btw I do use O/S authenticated userids but remote authentication has been
> disabled (deliberately). We are running Oracle on Unix so our batch jobs
use
> O/S authenticated ids.
>
>
> >From: "Gogala, Mladen" <[EMAIL PROTECTED]>
> >Reply-To: [EMAIL PROTECTED]
> >To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
> >Subject: RE: oracle authentication from windows
> >Date: Thu, 19 Jun 2003 12:19:59 -0800
> >
> >That, of course, will render your database totally insecure and open to
> >anybody
> >who can bring in a WinXP laptop, change the windoze username and log in
as
> >he pleases.
> >DBA that sets his production parameters the way Arup described deserves
to
> >be
> >publicly tortured by Bill O'Reilly in the "no spin zone".
> >
> >
> >Mladen Gogala
> >Oracle DBA
> >Phone:(203) 459-6855
> >Email:[EMAIL PROTECTED]
> >
> >-Original Message-
> >Sent: Thursday, June 19, 2003 3:46 PM
> >To: Multiple recipients of list ORACLE-L
> >
> >
> >Sure.
> >
> >Just declare these in your init.ora
> >
> >os_authent_prefix=OPS$
> >remote_os_authent=TRUE
> >
> >bounce the database, add a user called OPS$, e.g.
> >OPS$AK if your Windows login id is AK as
> >
> >create user ops$ak identified externally
> >
> >From windows connect as "/@servicename", e.g. sqlplus /@service1
> >
> >If it doesn't work, the OS user may be different. Use this query while
> >connected to the database from Windows cleint.
> >
> >SQL> select sys_context('USERENV','OS_USER') from dual;
> >
> >See what OS username comes up; use that instead.
> >
> >HTH.
> >
> >Arup Nanda
> >www.proligence.com
> >
> >
> >
> >- Original Message -
> >To: Multiple <mailto:[EMAIL PROTECTED]> recipients of list ORACLE-L
> >Sent: Thursday, June 19, 2003 1:10 PM
> >
> >We want our client users ( forms user ) to just enter windows password
and
> >then automatically able to get in to oracle .Is there a way oracle can
> >authenticate from windows ( or active directory ) . enbadding password in
> >runform.exe not an option .
> >
> >thanks,
> >-ak
> >
>
> _
> Help STOP SPAM with the new MSN 8 and get 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: david davis
> INET: [EMAIL PROTECTED]
>
> Fat City Network Services-- 858-538-5051 http://www.fatcity.com
> San Diego, California-- Mailing list and web hosting services
> -
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Arup Nanda
INET: [EMAIL PROTECTED]
Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Re: oracle authentication from windows
Got it . Thanks Arup .
-ak
- Original Message -
From:
Arup Nanda
To: Multiple recipients of list ORACLE-L
Sent: Friday, June 20, 2003 8:54 AM
Subject: Re: oracle authentication from
windows
AK,
The issue is not creating an id called OPS$
SYSTEM on XP, but on the database. Say, you created a user called OPS$SYSTEM
as
create user ops$system identified
externally;
The XP user should be SYSTEM, not OPS$SYSTEM, to
log on to this account.
Now suppose, your os_authent_prefix is set to ""
(null), then the Oracle user SYSTEM, not OPS$SYSTEM is authenticated
externally. If someone creates a user in XP called SYSTEM, she can
call
sqlplus /@service1
The OS user is SYSTEM, os_authent_prefix is null,
so Oracle will let the user be logged on as oracle user SYSTEM!
Therefore, always have a not null value in
os_authent_prefix, e.g. OPS$.
If the XP user is OPS$SYSTEM, the oracle user
should be OPS$OPS$SYSTEM, not OPS$SYSTEM. I hope you see the
difference.
HTH.
Arup
- Original Message -
From:
AK
To: Arup Nanda
Sent: Friday, June 20, 2003 10:46
AM
Subject: Re: oracle authentication from
windows
Arup,
why someone can't create account like
ops$system on xp and get in . If they can create system then y not
ops$system . Secondly OS authentication means operating system is going to
take care of auth. rite ? . It's up to OS not allow the users to change
their ids.
-ak
- Original Message -
From:
Arup
Nanda
To: Multiple recipients of list
ORACLE-L
Sent: Thursday, June 19, 2003 3:34
PM
Subject: Re: oracle authentication
from windows
Mladen,
This is precisely the content I have gone in
depth in my upcoming book where this practice of OPS$ accounts have been
discussed.
The security hole in OPS$ accounts is a bit
overrated. Chagnign username in Windows XP alone does not allow logging in
to the database directly if OPS$ accounts are used. What you are referring
to is setting the ORA_DBA group in Windows. Here is an excerpt from the
book:
"If OPS$ accounts must be used, make sure
that init.ora parameter os_authent_prefix is set to OPS$ or some other
value, not NULL. If it is null, as shown by an empty string "", the
security is severely threatened. Any one can create a userid called SYSTEM
in the OS and then logon without a password as the Oracle user SYSTEM. If
the os_authent_prefix is set to OPS$, then the corresponding user id in
Oracle will be OPS$SYSTEM, not SYSTEM. they are different
users."
As you might notice, OPS$ accounts are
somehow insecure, and I personally eschew them; but let's face it, in some
situations, like in the case AK mentioned, the use is required. When the
DBAs can do is to take some precautions to ensure security.
HTH.
Arup
- Original Message -
From:
Gogala,
Mladen
To: Multiple recipients of list
ORACLE-L
Sent: Thursday, June 19, 2003 4:19
PM
Subject: RE: oracle authentication
from windows
That, of course, will render your database
totally insecure and open to anybody
who can bring in a WinXP laptop, change the
windoze username and log in as he pleases.
DBA that sets his production parameters the way
Arup described deserves to be
publicly tortured by Bill O'Reilly in the "no
spin zone".
Mladen Gogala Oracle DBA Phone:(203)
459-6855 Email:[EMAIL PROTECTED]
-Original Message-From: Arup Nanda
[mailto:[EMAIL PROTECTED]Sent: Thursday, June 19, 2003
3:46 PMTo: Multiple recipients of list
ORACLE-LSubject: Re: oracle authentication from
windows
Sure.
Just declare these in your
init.ora
os_authent_prefix=OPS$remote_os_authent=TRUE
bounce the database, add a user called
OPS$, e.g. OPS$AK if your Windows login id
is AK as
create user ops$ak identified
externally
From windows connect as
"/@servicename", e.g. sqlplus /@service1
If it doesn't work, the OS user may be
different. Use this query while connected to the database from Windows
cleint.
SQL> select
sys_context('USERENV&#
Re: oracle authentication from windows
AK,
The issue is not creating an id called OPS$ SYSTEM
on XP, but on the database. Say, you created a user called OPS$SYSTEM
as
create user ops$system identified
externally;
The XP user should be SYSTEM, not OPS$SYSTEM, to
log on to this account.
Now suppose, your os_authent_prefix is set to ""
(null), then the Oracle user SYSTEM, not OPS$SYSTEM is authenticated
externally. If someone creates a user in XP called SYSTEM, she can
call
sqlplus /@service1
The OS user is SYSTEM, os_authent_prefix is null,
so Oracle will let the user be logged on as oracle user SYSTEM!
Therefore, always have a not null value in
os_authent_prefix, e.g. OPS$.
If the XP user is OPS$SYSTEM, the oracle user
should be OPS$OPS$SYSTEM, not OPS$SYSTEM. I hope you see the
difference.
HTH.
Arup
- Original Message -
From:
AK
To: Arup Nanda
Sent: Friday, June 20, 2003 10:46
AM
Subject: Re: oracle authentication from
windows
Arup,
why someone can't create account like ops$system
on xp and get in . If they can create system then y not ops$system . Secondly
OS authentication means operating system is going to take care of auth. rite ?
. It's up to OS not allow the users to change their ids.
-ak
- Original Message -
From:
Arup Nanda
To: Multiple recipients of list ORACLE-L
Sent: Thursday, June 19, 2003 3:34
PM
Subject: Re: oracle authentication from
windows
Mladen,
This is precisely the content I have gone in
depth in my upcoming book where this practice of OPS$ accounts have been
discussed.
The security hole in OPS$ accounts is a bit
overrated. Chagnign username in Windows XP alone does not allow logging in
to the database directly if OPS$ accounts are used. What you are referring
to is setting the ORA_DBA group in Windows. Here is an excerpt from the
book:
"If OPS$ accounts must be used, make sure that
init.ora parameter os_authent_prefix is set to OPS$ or some other value, not
NULL. If it is null, as shown by an empty string "", the security is
severely threatened. Any one can create a userid called SYSTEM in the OS and
then logon without a password as the Oracle user SYSTEM. If the
os_authent_prefix is set to OPS$, then the corresponding user id in Oracle
will be OPS$SYSTEM, not SYSTEM. they are different users."
As you might notice, OPS$ accounts are somehow
insecure, and I personally eschew them; but let's face it, in some
situations, like in the case AK mentioned, the use is required. When the
DBAs can do is to take some precautions to ensure security.
HTH.
Arup
- Original Message -
From:
Gogala,
Mladen
To: Multiple recipients of list
ORACLE-L
Sent: Thursday, June 19, 2003 4:19
PM
Subject: RE: oracle authentication
from windows
That, of course, will render your database
totally insecure and open to anybody
who can bring in a WinXP laptop, change the
windoze username and log in as he pleases.
DBA that sets his production parameters the way
Arup described deserves to be
publicly tortured by Bill O'Reilly in the "no
spin zone".
Mladen Gogala Oracle DBA Phone:(203)
459-6855 Email:[EMAIL PROTECTED]
-Original Message-From: Arup Nanda
[mailto:[EMAIL PROTECTED]Sent: Thursday, June 19, 2003 3:46
PMTo: Multiple recipients of list ORACLE-LSubject:
Re: oracle authentication from windows
Sure.
Just declare these in your
init.ora
os_authent_prefix=OPS$remote_os_authent=TRUE
bounce the database, add a user called
OPS$, e.g. OPS$AK if your Windows login id
is AK as
create user ops$ak identified
externally
From windows connect as
"/@servicename", e.g. sqlplus /@service1
If it doesn't work, the OS user may be
different. Use this query while connected to the database from Windows
cleint.
SQL> select
sys_context('USERENV','OS_USER') from dual;
See what OS username comes up; use that
instead.
HTH.
Arup Nanda
www.proligence.com
- Original Message -
From:
AK
To: Multiple recipients of list
ORACLE-L
Sent: Thursday, June 19, 2003
1:10 PM
Subject: oracle authentication
from windows
We want our client users ( forms user
RE: oracle authentication from windows
I disagree. Remote OS authentication is not inherently insecure in Windows like it is in Unix. If you prefix the account names with the domain name, a user would not only have to spoof the username, he would have to spoof the domain name too. At that point, you probably have bigger problems than access to your database. Also, in that situation, only the security token is going over the network, not your password in clear text. The caveat is that you should be using the *domain name* as the prefix, not OPS$. -Original Message- Sent: Friday, June 20, 2003 6:20 AM To: Multiple recipients of list ORACLE-L Hi Arup, Remote OS authentication whether with OPS$ or not is still a risk. You are intimating that SYSTEM is the only risky account involved here. What if any of the newly created OPS$ accounts have useful privileges. I have seen a similar application to the one described recently. There were forms within the application for administration and user management (in oracle, not the application) and the users who had access to these were assigned the DBA role and were of course external accounts. I think what you should add to your comment is that the issue is overrated is that any OPS$ / external accounts should not have any dangerous privileges granted and certainly not DBA. If you can guess the name of an admin account even if its OPS$ then the issue is still severe. cheers Pete -- Pete Finnigan email:[EMAIL PROTECTED] Web site: http://www.petefinnigan.com - Oracle security audit specialists Book:Oracle security step-by-step Guide - see http://store.sans.org for details. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Pete Finnigan INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Seefelt, Beth INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: oracle authentication from windows
This is an interesting one. I am currently going through (tortured) another
system audit. One of the many questions the auditors (I am being attacked
from all sides) had about the Oracle configuration was "Can remote
authenticated network users connect to the database?".
If auditors know this is a weakness, maybe it would be a good idea to avoid
its use.
btw I do use O/S authenticated userids but remote authentication has been
disabled (deliberately). We are running Oracle on Unix so our batch jobs use
O/S authenticated ids.
From: "Gogala, Mladen" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
Subject: RE: oracle authentication from windows
Date: Thu, 19 Jun 2003 12:19:59 -0800
That, of course, will render your database totally insecure and open to
anybody
who can bring in a WinXP laptop, change the windoze username and log in as
he pleases.
DBA that sets his production parameters the way Arup described deserves to
be
publicly tortured by Bill O'Reilly in the "no spin zone".
Mladen Gogala
Oracle DBA
Phone:(203) 459-6855
Email:[EMAIL PROTECTED]
-Original Message-
Sent: Thursday, June 19, 2003 3:46 PM
To: Multiple recipients of list ORACLE-L
Sure.
Just declare these in your init.ora
os_authent_prefix=OPS$
remote_os_authent=TRUE
bounce the database, add a user called OPS$, e.g.
OPS$AK if your Windows login id is AK as
create user ops$ak identified externally
From windows connect as "/@servicename", e.g. sqlplus /@service1
If it doesn't work, the OS user may be different. Use this query while
connected to the database from Windows cleint.
SQL> select sys_context('USERENV','OS_USER') from dual;
See what OS username comes up; use that instead.
HTH.
Arup Nanda
www.proligence.com
- Original Message -
To: Multiple <mailto:[EMAIL PROTECTED]> recipients of list ORACLE-L
Sent: Thursday, June 19, 2003 1:10 PM
We want our client users ( forms user ) to just enter windows password and
then automatically able to get in to oracle .Is there a way oracle can
authenticate from windows ( or active directory ) . enbadding password in
runform.exe not an option .
thanks,
-ak
_
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: david davis
INET: [EMAIL PROTECTED]
Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Re: oracle authentication from windows
Hi Arup, Remote OS authentication whether with OPS$ or not is still a risk. You are intimating that SYSTEM is the only risky account involved here. What if any of the newly created OPS$ accounts have useful privileges. I have seen a similar application to the one described recently. There were forms within the application for administration and user management (in oracle, not the application) and the users who had access to these were assigned the DBA role and were of course external accounts. I think what you should add to your comment is that the issue is overrated is that any OPS$ / external accounts should not have any dangerous privileges granted and certainly not DBA. If you can guess the name of an admin account even if its OPS$ then the issue is still severe. cheers Pete -- Pete Finnigan email:[EMAIL PROTECTED] Web site: http://www.petefinnigan.com - Oracle security audit specialists Book:Oracle security step-by-step Guide - see http://store.sans.org for details. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Pete Finnigan INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: oracle authentication from windows
Mladen,
This is precisely the content I have gone in depth
in my upcoming book where this practice of OPS$ accounts have been discussed.
The security hole in OPS$ accounts is a bit
overrated. Chagnign username in Windows XP alone does not allow logging in to
the database directly if OPS$ accounts are used. What you are referring to is
setting the ORA_DBA group in Windows. Here is an excerpt from the
book:
"If OPS$ accounts must be used, make sure that
init.ora parameter os_authent_prefix is set to OPS$ or some other value, not
NULL. If it is null, as shown by an empty string "", the security is severely
threatened. Any one can create a userid called SYSTEM in the OS and then logon
without a password as the Oracle user SYSTEM. If the os_authent_prefix is set to
OPS$, then the corresponding user id in Oracle will be OPS$SYSTEM, not SYSTEM.
they are different users."
As you might notice, OPS$ accounts are somehow
insecure, and I personally eschew them; but let's face it, in some situations,
like in the case AK mentioned, the use is required. When the DBAs can do is to
take some precautions to ensure security.
HTH.
Arup
- Original Message -
From:
Gogala, Mladen
To: Multiple recipients of list ORACLE-L
Sent: Thursday, June 19, 2003 4:19
PM
Subject: RE: oracle authentication from
windows
That, of course, will render your database totally
insecure and open to anybody
who
can bring in a WinXP laptop, change the windoze username and log in as he
pleases.
DBA
that sets his production parameters the way Arup described deserves to be
publicly tortured by Bill O'Reilly in the "no spin
zone".
Mladen Gogala Oracle DBA Phone:(203)
459-6855 Email:[EMAIL PROTECTED]
-Original Message-From: Arup Nanda
[mailto:[EMAIL PROTECTED]Sent: Thursday, June 19, 2003 3:46
PMTo: Multiple recipients of list ORACLE-LSubject: Re:
oracle authentication from windows
Sure.
Just declare these in your
init.ora
os_authent_prefix=OPS$remote_os_authent=TRUE
bounce the database, add a user called
OPS$, e.g. OPS$AK if your Windows login id is AK
as
create user ops$ak identified
externally
From windows connect as "/@servicename",
e.g. sqlplus /@service1
If it doesn't work, the OS user may be
different. Use this query while connected to the database from Windows
cleint.
SQL> select sys_context('USERENV','OS_USER')
from dual;
See what OS username comes up; use that
instead.
HTH.
Arup Nanda
www.proligence.com
- Original Message -
From:
AK
To: Multiple recipients of list
ORACLE-L
Sent: Thursday, June 19, 2003 1:10
PM
Subject: oracle authentication from
windows
We want our client users ( forms user )
to just enter windows password and then automatically able to get in to
oracle .Is there a way oracle can authenticate from windows ( or active
directory ) . enbadding password in runform.exe not an option
.
thanks,
-ak
Re: oracle authentication from windows
Got it . Thanks Arup .
- Original Message -
From:
Arup Nanda
To: Multiple recipients of list ORACLE-L
Sent: Thursday, June 19, 2003 12:45
PM
Subject: Re: oracle authentication from
windows
Sure.
Just declare these in your init.ora
os_authent_prefix=OPS$remote_os_authent=TRUE
bounce the database, add a user called
OPS$, e.g. OPS$AK if your Windows login id is AK
as
create user ops$ak identified
externally
From windows connect as "/@servicename",
e.g. sqlplus /@service1
If it doesn't work, the OS user may be different.
Use this query while connected to the database from Windows
cleint.
SQL> select sys_context('USERENV','OS_USER')
from dual;
See what OS username comes up; use that
instead.
HTH.
Arup Nanda
www.proligence.com
- Original Message -
From:
AK
To: Multiple recipients of list ORACLE-L
Sent: Thursday, June 19, 2003 1:10
PM
Subject: oracle authentication from
windows
We want our client users ( forms user )
to just enter windows password and then automatically able to get in to
oracle .Is there a way oracle can authenticate from windows ( or active
directory ) . enbadding password in runform.exe not an option .
thanks,
-ak
RE: oracle authentication from windows
That,
of course, will render your database totally insecure and open to anybody
who
can bring in a WinXP laptop, change the windoze username and log in as he
pleases.
DBA
that sets his production parameters the way Arup described deserves to be
publicly tortured by Bill O'Reilly in the "no spin
zone".
Mladen Gogala Oracle DBA Phone:(203) 459-6855
Email:[EMAIL PROTECTED]
-Original Message-From: Arup Nanda
[mailto:[EMAIL PROTECTED]Sent: Thursday, June 19, 2003 3:46
PMTo: Multiple recipients of list ORACLE-LSubject: Re:
oracle authentication from windows
Sure.
Just declare these in your init.ora
os_authent_prefix=OPS$remote_os_authent=TRUE
bounce the database, add a user called
OPS$, e.g. OPS$AK if your Windows login id is AK
as
create user ops$ak identified
externally
From windows connect as "/@servicename",
e.g. sqlplus /@service1
If it doesn't work, the OS user may be different.
Use this query while connected to the database from Windows
cleint.
SQL> select sys_context('USERENV','OS_USER')
from dual;
See what OS username comes up; use that
instead.
HTH.
Arup Nanda
www.proligence.com
- Original Message -
From:
AK
To: Multiple
recipients of list ORACLE-L
Sent: Thursday, June 19, 2003 1:10
PM
Subject: oracle authentication from
windows
We want our client users ( forms user )
to just enter windows password and then automatically able to get in to
oracle .Is there a way oracle can authenticate from windows ( or active
directory ) . enbadding password in runform.exe not an option .
thanks,
-ak
Re: oracle authentication from windows
Sure.
Just declare these in your init.ora
os_authent_prefix=OPS$remote_os_authent=TRUE
bounce the database, add a user called OPS$, e.g. OPS$AK if your Windows login id is AK as
create user ops$ak identified
externally
From windows connect as "/@servicename",
e.g. sqlplus /@service1
If it doesn't work, the OS user may be different.
Use this query while connected to the database from Windows cleint.
SQL> select sys_context('USERENV','OS_USER')
from dual;
See what OS username comes up; use that
instead.
HTH.
Arup Nanda
www.proligence.com
- Original Message -
From:
AK
To: Multiple recipients of list ORACLE-L
Sent: Thursday, June 19, 2003 1:10
PM
Subject: oracle authentication from
windows
We want our client users ( forms user ) to
just enter windows password and then automatically able to get in to oracle
.Is there a way oracle can authenticate from windows ( or active directory ) .
enbadding password in runform.exe not an option .
thanks,
-ak
Re: oracle authentication from windows
Hm I haven't tried on Windows, but... have you tried: IDENTIFIED EXTERNALLY??? using remote authentication I guess... HTH JL --- AK <[EMAIL PROTECTED]> wrote: > We want our client users ( forms user ) to just > enter windows password and then automatically able > to get in to oracle .Is there a way oracle can > authenticate from windows ( or active directory ) . > enbadding password in runform.exe not an option . > > thanks, > -ak __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jose Luis Delgado INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
oracle authentication from windows
We want our client users ( forms user ) to just enter windows password and then automatically able to get in to oracle .Is there a way oracle can authenticate from windows ( or active directory ) . enbadding password in runform.exe not an option . thanks, -ak
