Circumventing Security Prompts in Outlook 2003

[Michael fuerst]

Users on our network use either Outlook 2000, 2002, 2003

I have VBscript code (see below) in a custom form (developed in
Outlook 2002) in order to suppress the security prompt when reading an
email address. The code is based on the article, "Reinforcing
Dialog-Based Security", referenced on the web page
http://www.slipstick.com/outlook/esecup.htm#autosec


The code suppresses the security prompt correctly for users of Outlook
2000 and 2002. For users of Outlook 2003, the code has no effect,
and the user must process the security prompt. Any ideas?


***** The VBscript code

' Create the bypass file, the lines of which are in arr
arr = Array( _
"Set fso=CreateObject(""WScript.Shell"")", _
"While fso.AppActivate(""Microsoft Outlook"")=FALSE", _
" wscript.sleep 1000", _
"Wend", _
"fso.SendKeys ""a"",True", _
"fso.SendKeys ""{TAB}{TAB}"",True", _
"fso.SendKeys ""{Enter}"",True", _
"Set fso=Nothing" _
)
Set fso = CreateObject("Scripting.FilesystemObject")
Set fsofile = fso.CreateTextFile("bypass.vbs")
For i = Lbound(arr) to Ubound(arr)
fsofile.WriteLine arr(i)
Next
fsofile.Close
' Open Scripting shell and Run bypass file
Set wshShell = CreateObject("Wscript.Shell")
wshShell.Run("bypass.vbs")
' open outlook instance which, if above if stmt ran,
' will be intercepted by script shell running bypass file
Set oapp = CreateObject("Outlook.Application")
' this net line triggers the confirmation screen
Set obj = oapp.GetNamespace("MAPI")
' This is the line of code which generates the security prompt
' which in 2000 and 2002 is successfully suppressed, but in
' 2003 is not.
user = obj.CurrentUser
' close script object running bypass file
Set obj=Nothing
Set oapp = Nothing
Set wshShell=Nothing

 

[Sue Mosher [MVP-Outlook]]

Probably a subtle change in the dialog between versions. Frankly, I'm
surprised that Microsoft hasn't gone to some randomized dialog to prevent
SendKeys bypasses like this.

 

[Michael fuerst]

Probably a subtle change in the dialog between versions. Frankly, I'm
surprised that Microsoft hasn't gone to some randomized dialog to prevent
SendKeys bypasses like this.

--
Sue Mosher, Outlook MVP
Author of
Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers



(My original message deleted)

In any of Outlook 2000, 2002 or 2003, when my custom form is run w/o
the code to circumvent the security prompt, the keys "a", "{TAB}",
"{TAB}", "{ENTER}" are the ones which manually satisfy the security
prompt. This leads me to believe that Outlook 2003 has something
built in, or some form property to prevent the Sendkeys bypass. I
was hoping for some setting like the one in Outlook 2003 which must be
set for code in shared folders to be run. Any ideas along this line
or others?

Thanks in advance

 

[Sue Mosher [MVP-Outlook]]

I'm surprised that you're getting a security prompt at all with an Outlook
2003 form, since published forms don't display prompts for properties and
methods derived from the intrinsic Application and Item objects. Maybe the
issue is with your code? Or maybe you're using CDO, for which prompts can't
be suppressed except by the Exchange administrator.

--
Sue Mosher, Outlook MVP
Author of
Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

"Sue Mosher [MVP-Outlook]" <[email protected]> wrote in message

Probably a subtle change in the dialog between versions. Frankly, I'm
surprised that Microsoft hasn't gone to some randomized dialog to prevent
SendKeys bypasses like this.

In any of Outlook 2000, 2002 or 2003, when my custom form is run w/o
the code to circumvent the security prompt, the keys "a", "{TAB}",
"{TAB}", "{ENTER}" are the ones which manually satisfy the security
prompt. This leads me to believe that Outlook 2003 has something
built in, or some form property to prevent the Sendkeys bypass. I
was hoping for some setting like the one in Outlook 2003 which must be
set for code in shared folders to be run. Any ideas along this line
or others?

 

[Michael fuerst]

Looking back at my original post which contained the relevant source
code,
do the lines
Set obj = oapp.GetNamespace("MAPI")
' This is the line of code which generates the security prompt
' which in 2000 and 2002 is successfully suppressed, but in
' 2003 is not.
user = obj.CurrentUser
invoke CDO?

I there anything else in my original posted code which arouses
suspicion?

Are there any other things you can imagine that might lurk in my
source code to cause the porblem?

Rmember the security prompts are successfully circumvented for users
of Outlook 2000 and 2002.

I could email you a zipped version of the .oft file if you wish.

Thanks for any insights.

 

[Sue Mosher [MVP-Outlook]]

No. obj is an Outlook Namespace object, and you didn't indicate how you're
instantiating oapp. If this is Outlook form code, you should be using the
intrinsic Application object.

 

[Michael fuerst]

No. obj is an Outlook Namespace object, and you didn't indicate how you're
instantiating oapp. If this is Outlook form code, you should be using the
intrinsic Application object.

--
Sue Mosher, Outlook MVP
Author of
Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

Well the following code from my original example works only in Outlook
2000 and 2002. In 2003, the security promp appears.

Set oapp = CreateObject("Outlook.Application")
' this net line triggers the confirmation screen
Set obj = oapp.GetNamespace("MAPI")
user = obj.CurrentUser


HOWEVER, following your suggestion, the following works in 2003 as
well

Set obj = Application.GetNamespace("MAPI")
user = obj.CurrentUser

Any insights as to why?

Thanks in advance.

 

[Sue Mosher [MVP-Outlook]]

The intrinsice Application object in VBA and published forms is trusted in
Outlook 2003. See http://www.outlookcode.com/d/sec.htm

--
Sue Mosher, Outlook MVP
Author of
Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

"Sue Mosher [MVP-Outlook]" <[email protected]> wrote in message

No. obj is an Outlook Namespace object, and you didn't indicate how you're
instantiating oapp. If this is Outlook form code, you should be using the
intrinsic Application object.

--
Sue Mosher, Outlook MVP
Author of
Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers



news:[email protected]...

Well the following code from my original example works only in Outlook
2000 and 2002. In 2003, the security promp appears.

Set oapp = CreateObject("Outlook.Application")
' this net line triggers the confirmation screen
Set obj = oapp.GetNamespace("MAPI")
user = obj.CurrentUser


HOWEVER, following your suggestion, the following works in 2003 as
well

Set obj = Application.GetNamespace("MAPI")
user = obj.CurrentUser

Any insights as to why?