Jump to content

Jordan_Tsafaridis

Members
 View Profile  See their activity

  • Posts

    106

  • Joined

  • Last visited

 Content Type 

Blog Entries posted by Jordan_Tsafaridis

  1. Jordan_Tsafaridis
    Αγαπητοί συνάδελφοι της κοινότητας είναι χαρακτηριστικό ότι είναι εξαιρετικά σπάνια η περίπτωση κατά την οποία θα δείτε ένα security update για οτιδήποτε σχετίζεται με τον Forefront TMG firewall. Εντούτοις, στο June 2011 security bulletin περιλαμβάνεται το update MS11-040 το οποίο επιλύει ένα privately reported vulnerability στον Forefront TMG client το οποίο ενδεχομένως μπορεί να επιτρέψει ένα remote code execution. Σας εφιστώ την προσοχή σας διότι αυτό το security εφαρμόζεται μόνον στον Forefront TMG client, και όχι στο firewall. Επιπροσθέτως, σας ενημερώνω ότι δεν εφαρμόζεται στις προηγούμενες εκδόσεις του ISA firewall client.

    Πριν από την εφαρμογή του MS11-040 update, η τελευταία/πρόσφατη έκδοση του Forefront TMG client ήταν το build 7.0.7734.100. Μετά την εφαρμογή του MS11-040 update, το νέο build number θα είναι το 7.0.7734.182.


    Ελπίζω ότι το παραπάνω θα σας φανεί ιδιαιτέρως χρήσιμο.

  2. Jordan_Tsafaridis
    Αγαπητοί συνάδελφοι της κοινότητας, είναι γνωστό ότι πάρα πολύ από εμάς εργάζονται σε μικτά περιβάλλοντα. Αυτό σημαίνει ότι πρέπει να συντηρούμε υπολογιστικά συστήματα βασισμένα σε περιβάλλον Microsoft Windows, σε συνδυασμό με Linux, HP/UX, IBM AIX. Το συγκεκριμένο άρθρο σχετίζεται με την διαδραστικότητα μεταξύ Microsoft Windows Active Directory και IBM AIX, όπου το IBM AIX παρουσιάζει ένα σημαντικό κενό ασφάλειας.
     
    Για αποφυγή παρεξηγήσεων παραθέτω αυτούσιο το άρθρο στην Αγγλική γλώσσα καθώς και τα σχετικά links :
     
    http://www.cvedetails.com/vulnerability-list/vendor_id-14/product_id-17/IBM-AIX.html
     
    http://www.cvedetails.com/cve/CVE-2011-1561/
     

    Vulnerability Details : CVE-2011-1561


    The LDAP login feature in bos.rte.security 6.1.6.4 in IBM AIX 6.1, when
    ldap_auth is enabled in ldap.cfg, allows remote attackers to bypass
    authentication via a login attempt with an arbitrary password.


    Publish Date : 2011-04-05 Last Update Date : 2011-04-05












    Collapse All
     
    Expand All
     
    Select
     
    Select&Copy
     

    Scroll To 


    Comments 

    External Links 

    Click here if you can't see the dropdown menus or if you want to expand them now
     
     


    -
    CVSS Scores & Vulnerability Types


    Cvss Score 6.8 Confidentiality Impact Partial
    (There is considerable informational disclosure.) Integrity Impact Partial
    (Modification of some system files or
    information is possible, but the attacker does not have control over
    what can be modified, or the scope of what the attacker can affect is
    limited.) Availability Impact Partial
    (There is reduced performance or interruptions in resource availability.) Access Complexity Medium
    (The access conditions are somewhat specialized. Some preconditions must be satistified to exploit) Authentication Not required
    (Authentication is not required to exploit the vulnerability.) Gained Access None Vulnerability Type(s) Bypass a restriction or similar CWE ID 287  



    -
    Products Affected By CVE-2011-1561

    # Product Type Vendor Product Version Update Edition Language

    1 OS IBM AIX 6.1


    Details Vulnerabilities


    -
    Number Of Affected Versions By Product



    Vendor

    Product

    Vulnerable Versions
    IBM AIX
    1  
     



    -
    References For CVE-2011-1561


    http://aix.software.ibm.com/aix/efixes/security/ldapauth_advisory.asc CONFIRM

    http://secunia.com/advisories/43968
    SECUNIA 43968
    http://securitytracker.com/id?1025273
    SECTRACK 1025273
    http://www-01.ibm.com/support/docview.wss?uid=isg1IZ97416
    AIXAPAR IZ97416
    http://www.vupen.com/english/advisories/2011/0836
    VUPEN ADV-2011-0836  
     


     







    -
    Metasploit Modules Related To CVE-2011-1561

    There are not any metasploit modules related to this vulnerability (Please visit www.metasploit.com for more information)
     
  3. Jordan_Tsafaridis
    Αγαπητοί συνάδελφοι της κοινότητας, πιθανώς να έχετε βρεθεί και εσείς στην θέση, όπου σε μια εγκατάσταση Microsoft Exchange Server 2010/2010SP1 θα παρατηρήσατε μια σειρά λαθών τα οποία εμφανίζονται στο Application log αφότου το Microsoft
    Exchange RPC Client Access service έχει ξεκινήσει. Έχω παρατηρήσει ότι το συγκεκριμένο λάθος εμφανίζεται σε servers στους οποίους είναι εγκατεστημένο μόνον το Mailbox Role. Παρότι και ο CAS role έχει ένα service το οποίο επίσης ονομάζεται Microsoft Exchange RPC Client Access το συγκεκριμένο μήνυμα λάθους δεν έχει παρατηρηθεί ότι εμφανίζεται όταν υπάρχει εγκατεστημένο μόνο το CAS Role στον server χωρίς το Mailbox  Role.



    Όλα τα λάθη προέρχονται από το Performance counter category name MSExchange RpcClientAccess.

    Αναλυτικότερα - Event ID 106, Source MSExchange Common, Level Error:

    Log Name:      Application
    Source:        MSExchange Common
    Date:          24.1.2011 21:25:17
    Event ID:      106
    Task Category: General
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      ServerName.fqdn.local
    Description:
    Performance
    counter updating error. Counter name is RPC Requests, category name is
    MSExchange RpcClientAccess. Optional code: 3. Exception: The exception
    thrown is : System.InvalidOperationException: The requested Performance
    Counter is not a custom counter, it has to be initialized as ReadOnly.
       at System.Diagnostics.PerformanceCounter.Initialize()
       at System.Diagnostics.PerformanceCounter.set_RawValue(Int64 value)
       at Microsoft.Exchange.Diagnostics.ExPerformanceCounter.set_RawValue(Int64 value)
    Last
    worker process info : System.UnauthorizedAccessException: Access to the
    registry key
    'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\Transport' is
    denied.
       at Microsoft.Win32.RegistryKey.Win32Error(Int32 errorCode, String str)
      
    at Microsoft.Win32.RegistryKey.CreateSubKey(String subkey,
    RegistryKeyPermissionCheck permissionCheck, RegistrySecurity
    registrySecurity)
       at Microsoft.Exchange.Diagnostics.ExPerformanceCounter.GetLastWorkerProcessInfo()

    Θα πρέπει σε αυτό το σημείο να σημειώσουμε ότι σε καμία περίπτωση δεν πρέπει να ανησυχείτε για αυτό το συγκεκριμένο λάθος. Η Microsoft έχει δημισιέυσει το παρακάτω άρθρο KB982679 - Event ID 106 is logged when you start the RPC Client Access service on Exchange Server 2010. Μάλιστα αναφέρει επακριβώς τα παρακάτω :


    This problem occurs because the performance counters of the RPC
    Client Access service are not installed when you install only the
    Mailbox role on an Exchange Server 2010 server. However, this does not
    affect the functionality of the Exchange Server 2010 server.

    Οπωσδήποτε σε καμία περτωση δεν είναι ωραίο από την πλευρά ενός τεχνικού ΙΤ να παρουσιάζονται τόσα πολλά μηνύματα λαθών στον Event Viewer αμέσως μετά την επανεκκίνηση του Microsoft Exchange RPC Client Access service. Για τον λόγο αυτό παρακάτω παρουσιάζω τον τρόπο με τον οποίο εγκαθιστούμε manually τους RPC Client Access performance counters.

    Εγκατάσταση - Προσθήκη των  RPC Client Access performance counters

    Εκκινούμε τον Exchange Management Shell και γράφουμε τις παρακάτω εντολές, όπου "C" ο οδηγός δίσκου στον οποίο είναι εγκατεστημένος ο Microsoft Exchange 2010 Server.
    Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Setup New-PerfCounters -DefinitionFileName "C:\Program Files\Microsoft\Exchange
    Server\V14\Setup\Perf\RpcClientAccessPerformanceCounters.xml"
     

    Κάνουμε Restart τον server ή το Microsoft Exchange RPC Client Access service. Πλέον τα μηνύματα λάθους δεν εμφανίζονται, γεγονός το οποίο κάνει τους administrators χαρούμενους…
     

    Links:

    KB982679 - Event ID 106 is logged when you start the RPC Client Access service on Exchange Server 2010 How to fix/repair broken Exchange 2007 counters How to unload/reload performance counters on Exchange 2010  
  4. Jordan_Tsafaridis
    Αγαπητοί συνάδελφοι της κοινότητας,
     
    Στις 26-4-2011, έλαβε χώρα ένα εξαιρετικά εμπεριστατομένο τεστ αξιοπιστίας και ασφάλειας μεταξύ Microsoft Internet Explorer 9 και Google Chrome. Σας παραθέτω παρακάτω τα αποτελέσματα αυτού του τεστ αυτούσιο στην Αγγλική γλώσσα καθώς και τα σχετικά link στο διαδίκτυο. (Ελπίζω να σας φανεί χρήσιμο)
     
    Last week I looked at a fascinating sample of malware that specifically targeted users of Google Chrome.
    Over the past few days, I’ve been looking more closely at this
    particular malware attack, which appears to be widespread and extremely
    persistent.
     
     
     
    Social engineering has become the dominant method of distribution for
    fake antivirus software. And most modern browsers, with one exception,
    do a terrible job of dealing with this type of threat. Current builds of
    Chrome display a terrible flaw that puts you at greater risk than its
    competitors. In my testing, a malware author was able to exploit Chrome
    in four easy clicks. In stark contrast, Internet Explorer 9 used some
    new technology to flag the exact same sites and files as suspicious,
    providing unmistakable warnings that have been shown to stop 95% of
    these attacks in their tracks.
     
     
     
    I’ve captured the experience for both browsers in these two videos and in an accompanying screenshot gallery
    so you can see for yourself. And if you make it to page 3, you’ll read
    about the new reputation-based technology that’s given IE9 the lead.
     
     
     
    First a little background. Fake antivirus software has been around for
    at least seven years, but this category of attack has exploded in
    popularity among bad guys in recent months. The technique is simple
    social engineering, and it works by scaring the target into thinking
    their system has been infected with a virus (or a whole bunch of them)
    and then offering to fix the problem—for a fee. The fake AV software
    often downloads additional Trojans and can actually cause the sort of
    problems it claims to be solving.
     
     
     
    Here’s how it goes when you’re using Google Chrome 10 on Windows 7.
    Notice the attention to detail that the malware authors used in this
    attack. The dialog boxes and warning screens certainly look like they’re
    part of Google Chrome. (I recommend clicking the full-screen button in
    the lower right corner of the video clips below so you can see all the
    details in each one.)
     
     
     

     
     
    Now here’s an attack from the same set of search results, this time
    gathered using Internet Explorer 9. The fake scan is a pretty decent
    imitation of a Windows 7 security screen. But the result is different.
     
     
     

     
     
     
    By Ed Bott | April 25, 2011, 7:23pm PDT

    Malware authors target Google Chrome
    Every time I write about Internet Explorer, it’s usually a matter of minutes—sometimes even seconds—until someone in the Talkback
    section proclaims, smugly, that they’ve switched to Google Chrome or
    Firefox and are therefore immune from malware attacks.

    They’re wrong, and malware authors have begun preying on users of
    alternative browsers to push dangerous software, including Trojans and
    scareware. The problem is that most malware attacks aren’t triggered by
    exploits that target vulnerabilities in code. Instead, according to one recent study,
    “users are four times more likely to come into contact with social
    engineering tactics as opposed to a site serving up an exploit.”

    Follow-up: Malware attempts that use Apple-focused social
    engineering are now in the wild. I just found one via Google Image
    search. See for yourself: What a Mac malware attack looks like.

    I found a perfect example yesterday, thanks to an alert from
    Silverlight developer Kevin Dente. He had typed in a simple set of
    search terms—Silverlight datagrid reorder columns—at Google.com, using the Google Chrome browser on Windows. You can follow along with what happened next in the screenshot gallery that accompanies this post.

    The first page of Google search results included several perfectly
    good links, but the sixth result was booby trapped. Clicking that link
    in Google Chrome popped up this dialog box:



    That led to a basic social engineering attack, but this one has a
    twist. It  was customized for Chrome. If you’ve ever seen a Google
    Chrome security warning, you’ll recognize the distinctive, blood-red
    background, which this malware author has duplicated very effectively.



    After the fake scan is complete, another dialog box comes up, warning
    that “Google Chrome recommends you to install proper software.”



    That’s terrible grammar, and this social-engineering attack is likely
    to fail with an English-speaking victim, who should be suspicious of
    the odd wording. But a user whose primary language is something other
    than English might well be fooled. And the malware author has
    anticipated the possibility that you might click Cancel in the dialog
    box. If you do, it still tries to download the malicious software.

    Each time I visited this page, the download I was offered was
    slightly different. My installed antivirus software (Microsoft Security
    Essentials) didn’t flag it as dangerous. When I submitted it to VirusTotal.com,
    only five of the 42 engines correctly identified it as a suspicious
    file. Less than 8 hours later, a second scan at VirusTotal was a little
    better. This time, eight engines confirmed that the file was suspicious.
    Microsoft’s virus definitions had been updated and a scan identified
    the rogue file as Win32/Defmid.



    Panda and Prevx identified the file as “Suspicious” and “Medium risk
    malware,” respectively. BitDefender, F-Secure, and GData flagged it as
    “Gen:Trojan.Heur.FU.quX@am@e97ci.” AntiVir detected it as
    “TR/Crypt.XPACK.Gen.” Kaspersky says it is
    “Trojan-Downloader.Win32.FraudLoad.zdul.” Every other antivirus engine,
    as of a few minutes ago, waved this suspicious executable right through.

    Meanwhile, back in the browser, Google Chrome’s warnings are
    completely generic. If you download the software it shows up in the
    Downloads folder looking perfectly innocent.

    Interestingly, this set of “poisoned” search terms also affected
    Bing, although the dangerous search result was on a different site,
    which didn’t show up until the fifth page of search results. And the
    download that it offered was, apparently, a completely different
    Trojan/scareware product. But the end result would have been the same,
    regardless of which browser I was using.

    This case study shows that malware authors are beginning to adapt to
    changing habits of PC users. There’s nothing inherently safer about
    alternative browsers—or even alternative operating systems, for that
    matter—and as users adapt, so do the bad guys.

    Be careful out there.
     
     
  5. Jordan_Tsafaridis
    Αν και αρχικώς τα συγκεκριμένα Vulnerabilities είχαν εντοπιστεί στις 5 Μαρτίου 2011, εντούτοις μια προσεκτική ανάλυση από την ομάδα ασφαλείας του FortiNet Security Blog, κατέδειξε την επικυνδυνότητά τους. Παρακάτω σας παραθέτω το πρωτότυπο κείμενο στην Αγγλική γλώσσα προς μελέτη.
     


    We are pretty busy these days with malicious samples on Android. You probably haven’t missed DroidDream (Android/DrdDream.A!tr) which trojaned several applications on the Android Market and several blog posts on the matter:

    Lookout explains how the malware was discovered, which applications it targets
    and whether you should be concerned or not. By the way, we thank them
    for sharing samples with us.
    AndroidPolice explains the malware uses the rageagainstthecage root exploit, and that
    malicious applications have been pulled out of the market
    Kaspersky reminds the dark sides of the Android Market and iPhone jailbreaking AegisLab explains the malware uses JNI and collects /proc information (the
    sample they analyze is slightly different from the one we refer to in
    this post).

    But there are still a few additional questions – that I intend to cover in this blog post.

    DroidDream does not use ONE vulnerability but TWO

    In the sample we analyzed, those files are located in the asset directory of the package:

    $ ls -al -rw-r--r-- 1 axelle users 15295 Jan 14 11:04 exploid
    -rw-r--r-- 1 axelle users 3868 Jan 14 11:04 profile
    -rw-r--r-- 1 axelle users 5392 Jan 14 11:04 rageagainstthecage
    -rw-r--r-- 1 axelle users 14076 Feb 15 14:59 sqlite.db
    drwxr-xr-x 4 axelle users 4096 Mar 2 11:04 www


    exploid corresponds to this local root exploit, and it is tried in case rageagainstthecage
    does not work. The idea behind rageagainstthecage create many
    processes, reach the maximum limit of user processes, so that the next
    time the adbd process is run it cannot surrender its root permissions.
    Both files are local root privilege escalation exploits. Below, the logs
    show exploid was called but failed on my android emulator:

    W/System.err( 246): java.io.IOException: Error running exec(). Commands: [/data/data/com.droiddream.bowlingtime/files/exploid,
    /dev/block/mtdblock1, yaffs2] Working Directory: null Environment: null
    D/AudioSink( 31): bufferCount (4) is too small and increased to 12
    W/MediaPlayer( 240): info/warning (1, 44)
    W/System.err( 246): at java.lang.ProcessManager.exec(ProcessManager.java:196)
    W/System.err( 246): at java.lang.Runtime.exec(Runtime.java:225)
    W/System.err( 246): at java.lang.Runtime.exec(Runtime.java:313)
    W/System.err( 246): at java.lang.Runtime.exec(Runtime.java:246)
    W/System.err( 246): at com.android.root.udevRoot.runExploid(udevRoot.java:134)
    W/System.err( 246): at com.android.root.udevRoot.go4root(udevRoot.java:230)
    W/System.err( 246): at com.android.root.Setting.onCreate(Setting.java:265)


    profile is a shell – we will talk about this one later.
    sqlite.db actually isn’t a SQLite database but an Android package named
    com.android.providers.downloadsmanager the malware will install on the
    infected device. Finally the www directory contains the real assets
    (images) used by the real foreground application (e.g bowling game).

    DroidDream posts the victim’s IMEI, IMSI etc – but no need to root a phone to do that

    One of the first things the malware does is post the phone’s IMEI,
    IMSI, Android version to a remote website whose URL is XOR encrypted.
    The key is hard-coded in another class, named Setting.class. A little
    bit of Java decompiling and copy/paste in a quick n’ dirty standalone
    program, and we decrypt the URL:





    The information is posted (HTTP POST) using the XML format:

    <?xml version="1.0" encoding="UTF-8"?> <Request>
    <Protocol>1.0</Protocol>
    <Command>0</Command>
    <ClientInfo>
    <Partner>502</Partner>
    <ProductId>10011</ProductId>
    <IMEI>YOUR IMEI</IMEI>
    <IMSI>YOUR IMSI</IMSI>
    <Modle>YOUR DEVICE SDK</Modle>
    </ClientInfo>
    </Request>


    Posting the IMEI, IMSI etc is not the real goal of the malware, since
    you do not need to root the phone for that, but only the
    READ_PHONE_STATE permission.

    A r00t shell – that’s awesome (from a malware author’s perspective! )

    It seems that what the malware author really wanted to install is the
    profile binary (see above, in the assets directory). Once the phone is
    rooted, the malware copies profile to /system/bin/profile and sets root
    permissions to the file:

    chown 0.0 /system/bin/profile chown root.root /system/bin/profile
    chmod 6755 /system/bin/profile


    Actually, the /system/bin/profile file also acts as an r00ted
    indicator: if the file exists, the phone has been rooted, if not, the
    malware tries to root the phone. So, as a quick hack, some developers
    suggest to create a dummy /system/bin/profile on your phone and be
    immune to the malware (more exactly the malware won’t be able to
    operate).


     
    A quick analysis of profile with a disassembler shows this executable
    merely does a setgid, then a setuid, and finally executes (excv) a
    shell. The malware author installed a root shell on the infected device.
    But so far, this shell is not used remotely.
     
    To me, it looks more like the work of a (dark) hacker than what
    cyber-criminals usually do. Unless the next step is to download a
    malware upgrade (via the downloads manager package) and monetize this
    root shell…

    Thanks to David Maciejak for his help on Android vulnerabilities.

    – the Crypto Girl

     
     

    Author bio:
    Axelle Apvrille's initial field of expertise is cryptology, security
    protocols and OS. She is a senior antivirus analyst and researcher for
    Fortinet, where she more specifically looks into mobile malware.
    Ελπίζω ότι θα το βρείτε ιδιαίτερα χρήσιμο.
     
     
  6. Jordan_Tsafaridis
    Ένα νέο πρόβλημα δημοσιεύτηκε στην ιστοσελίδα Vupen Security (http://www.vupen.com/english/advisories/2011/1162), και αφορά ένα σημαντικό κενό ασφάλειας το οποίο ανιχνεύθηκε στα προϊόντα της CheckPoint. Το αυθεντικό κείμενο παρουσιάζεται παρακάτω :
     

    VUPEN ID

    VUPEN/ADV-2011-1162


    CVE ID


    CVE-2011-1827

     


    CWE ID

    Available in Customer Area



    CVSS V2

    Available in Customer Area


    Rated as


    Critical 



    Impact

    Available in Customer Area




    Authentication Level

    Available in Customer Area




    Access Vector

    Available in Customer Area


    Release Date

    2011-05-03


    Share

















    Technical Description
    A vulnerability has been
    identified in Check Point products, which could be exploited by remote
    attackers to compromise a vulnerable system. This issue is caused by an
    error in the SSL Network Extender (SNX), SecureWorkSpace and Endpoint
    Security On-Demand application when deployed through a browser, which
    could allow attackers to execute arbitrary code by tricking a user into
    visiting a specially crafted web page.
     




    Affected Products Check Point SecurePlatform

    Check Point IPSO6

    Check Point Connectra

    Check Point VSX
     



    Solution 
    Apply patches :
     
    https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk62410
     



    References  
     
    http://www.vupen.com/english/advisories/2011/1162
    https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk62410
     



    Credits   
     
    Vulnerability reported by Johannes Greil (SEC Consult).
     



    Changelog   
     
    2011-05-03 : Initial release

     
  7. Jordan_Tsafaridis
    1. Εισαγωγή


     

    Ορισμένες φορές η επίλυση προβλημάτων τα οποία οφείλονται σε λάθος προγραμματισμό των publishing rules μπορεί να εξελεχθεί σε μια επίπονη και απαιτητική διαδικασία. Ο κύριος λόγος είναι ότι υπάρχει μια λεπτή διαχωριστική γραμμή μεταξύ του published server
    και του firewall (στην συγκεκριμένη περίπτωση του ISA/TMG Server). Συνεπώς το ερώτημα είναι σε πιο σημείο έχει διαραγεί η επικοινωνία? Μήπως ο ISA/TMG Server δεν επιτρέπει την σύνδεση από έξω (outside) ή μήπως ο published
    server είναι αυτός ο οποίος δεν απαντά στα αιτήματα τα οποία αποστέλλει ο ISA/TMG Server?


     
    Στο σημείο αυτό θα πρέπει να αναφέρω ότι σημαντική βοήθεια στο να κατανοήσουμε πως λειτουργούν τα πρωτόκολα προσφέρει η σειρά των άρθρων τουν Jim Harrison σχετικά με το RPC over HTTP καθώς επίσης συμβάλει και στην ανάπτυξη μιας μεθοδολογίας επίλυσης προβλημάτων τα οποία είναι δυνατόν να προκύψουν όταν υλοποιούμε το publishing Outlook Anywhere διαμέσου του ISA Server 2006/TMG 2010.

     


    2. Γενικές Συστάσεις


     

    Η κύρια σύσταση είναι η χρήση των official white paper στα οποία παρουσιάζεται μια βήμα προς βήμα configuration μέθοδος για το publishing του OWA 2007 διαμέσου του ISA Server 2006. Αντιστοίχως για τον TMG 2010 το official white paper μπορείτε να το κατεβάσετε κάνοντας κλικ εδώ.


     

    2.1. Επιλογές Authentication


     

    Όταν υλοποιούμε το publishing του OWA 2007/2010 διαμέσου του ISA Server 2006/TMG 2010 έχουμε δύο επιλογές για την ρύθμιση του FBA (Forms Based Authentication):

      

    ·         Επιλογή 1 (Η πιο συνήθης): Απενεργοποιούμε το Forms Base Authentication στο Exchange OWA side και ενεργοποιούμε το FBA στον ISA Server 2006/TMG 2010 Web Listener.

     

     

    Εικόνα 1– Authentication properties.

     


    Σημείωση : Όταν έχουμε  επιλεγμένο το Basic Authentication στο OWA όπως αυτό παρουσιάζεται στην παραπάνω εικόνα,
    θα πρέπει να διασφαλίσουμε ότι στο Authentication Delegation tab στον ISA Server 2006/TMG 2010, το
    OWA Publishing rule έχει επιλεγμένο το Basic Authentication.

     

    ·         Επιλογή 2 (Σπάνια Χρησιμοποιείται): Δεν εφαρμόζουμε το authenticate στον ISA Server 2006/TMG 2010 αλλά χρησιμοποιούμε το Forms Based Authentication στον Exchange Server:

     

     

    Εικόνα 2 – Η δεύτερη επιλογή για το authentication.

     

     

    2.2. Θέματα τα οποία αφορούν τα Certificates

     

    Όταν υλοποιούμε το publishing του OWA 2007/2010 μπορούμε να χρησιμοποιήσουμε το SAN Certificate στο
    Exchange OWA side. Εντούτοις το FQDN name το οποίο ενφανίζεται στο To Tab στον ISA Server 2006TMG 2010 OWA Publishing rule είναι υποχρεωτικό να ταυτίζεται με το first name στο SAN Certificate όπως ακριβώς απεικονίζεται στην εικόνα παρακάτω :

     

     

    Εικόνα 3 – Λεμπτομέριες του SAN Certificate. 

     





     


     

    3. Θέματα Troubleshooting - Τα πιο πιθανά σενάρια (Το κείμενο είναι στην Αγγλική γλώσσα διότι τα θέματα αυτά έχουν συλλεχθεί από διάφορα forums)


     

    3.1.
    I can access the OWA page, authenticate using Forms Base but after the
    first authentication I receive another page asking for authentication
    again.

     

    Make
    sure that you have forms base authentication enabled only on ISA Server
    or only on the Exchange. Review the session 2.1 for more information.

     

    3.2. After authenticate on the OWA Forms Base Authentication I receive the error: Target principal name is incorrect.

     

    Make sure that of the following:

    ·         The name on the certificate that is installed on the Exchange Server matches with the name on the To tab for the OWA Publishing Rule on ISA Server. Review session 2.3 for more information.

    ·         The Exchange Server name (usually the CAS Server) is correct on the To tab on the OWA Publishing Rule on ISA Server.

    ·         ISA Server 2006 can correctly resolve this FQDN for the correct IP.

     

    3.3. I cannot even access the OWA Page, when I type the address https://mail.contoso.com on IE I receive the error: 403 Access Forbidden.

     

    When you create an OWA 2007 Publishing Rule only the following paths are allowed by default:

     

     

    Εικόνα 4 – Default paths for OWA 2007.

     

    When you type https://mail.contoso.com
    without use /owa or the other paths that are allowed by this rule it is
    expected to receive the 403 since ISA Server is restricting the paths
    for security purpose.

     

    3.4. I’m typing the address https://mail.contoso.com/owa on Internet Explorer, I can reach the FBA page, authenticate but after that I’m receiving the error: 404 Not Found.

     

    Make sure that the ISA Server 2006 can reach the Exchange Server that it is using on the To tab. Try to validate using the following methods:

    ·         From
    the ISA Server ping the FQDN name of the Exchange Server that is in use
    on the OWA Publishing to make sure that is resolving to the correct IP.

    ·         Telnet
    from ISA Server to the FQDN of the Exchange Server and use the port
    that appears on the Bridging tab as show below and see if you receive an
    answer (telnet exc2007.contoso.msft 443):

     



    Εικόνα 5 – Bridging Tab.

     

    ·         If
    all tests succeed then enable logging on ISA Server (ISA Console /
    Monitoring / Logging) and create a filter where the source is the
    External network. Try to reproduce the problem and check if you see the
    error below:

     

     

    Εικόνα 6 – Failed connection attempt to the Exchange Server (error 10060).

     

    The error 10060 showed above means that the connection timed out. Usually this error means:

    ·         Connectivity issue between ISA Server and the Exchange Server that is being used by this publishing rule.

    ·         The ISA Server is sending the package by for some reason the Exchange Server is not replying in appropriate manner.

     

    Review the following:

    ·         There
    is any other firewall in between ISA Server and the Exchange Server? If
    it does, can we bypass that? If we can’t bypass, make sure that the
    ports are allowed in both ways. Use PortQuery to test that from the ISA to the Exchange Server.

    ·         A netmon trace on the internal NIC of the ISA and on the Exchange Server might show what is happening.

    ·         The IIS Logs on the OWA also will help to see if the traffic is hitting the OWA Server.

     

     

    3.5. I’m typing the address https://mail.contoso.com/owa on Internet Explorer, I can reach the FBA page, authenticate but after that I’m receiving the error: 10061 Connection Refused.

     

    The error code 10061 means: A connection was refused by the destination host.
    This error means that ISA Server tried to contact the published server
    (in this case the Exchange Server) and this server refused the request
    for some reason.

     

    This
    usually happens because ISA Server tried to contact the published
    server on a port that is not allowed on the destination server. Review
    the Bridging tab on the OWA Publishing rule to make sure that this port matches with the port that OWA is using on the IIS web site:

     



    Εικόνα 7 – IIS properties matching with the Bridging tab.

     

    If you also use the ISA Server Monitoring Logging you will see the error below:

     

     

    Εικόνα 8 – Failed connection attempt to the Exchange Server (error 10061).

     

    For more information about the error code see the ISA Server 2006 Logging Fields and Values article. For TMG 2010 the link is here.


     

    3.6.
    I can authenticate on the FBA page, I can see my OWA inbox but I’m
    unable to create a new message and the buttons on the toolbar doesn’t
    work. Everything works fine internally (bypassing the ISA Server).

     

    Don’t
    set your mind to think that if works internally and externally doesn’t
    then the issue is on the ISA Server. There are some 3rd Party ISAPI filters (for example the one mentioned on KB 924228
    ) that could be installed on the Exchange Server (Backend, FrontEnd,
    CAS or Mailbox Server) that can cause this behavior when the traffic
    crosses the ISA Server. A more in depth investigation will be necessary
    to determine the root cause in this situation.

     

     

    4. Συμπέρασμα

     

    Όπως αντιλαμβάνεστε, η προσπάθεια στο άρθρο αυτό είναι να παρουσιαστούν τα πλέον συνήθη προβλήματα τα οποία μπορούν να προκύψουν όταν υλοποιούμε το OWA publishing διαμέσου του ISA Server 2006/TMG 2010. Εάν παρόλα αυτά, τα προβλήματα συνεχίζονται καλό είναι σε πρώτη φάση να χρησιμοποιήσετε το ISA Server BPA
    και TMG 2010 Server PBA αντίστοιχα, και να ελένξουμε σχοαλστικά μήπως υπάρχει κάποια πρόταση για την επίλυση του προβλήματος και εν συνεχεία να ζητήσουμε την βοήθεια του Microsoft ISA/TMG Support.and check if there is any recommendation on that.

×
×
  • Create New...