Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 2 subscribers
  • Views 415 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Understanding AD Authentication

scmiles
Okay I have a case opened with Astaro that is going really slow, and I am throwing this out to the community to possibly get some help.  I am trying to understand how the AD Authentication works with respect to Auto create users.

Here is our situation, we have around 50,000 users in AD that could potentially login to the End User Portal.  I have the "Active Directory configuration" properly connected to AD.  At first I had the End User Portal (EUP), setup to allow all users, however the only way I could get a user to log in was to "pre-fetch" the user.  If any of you have tested this with large directories s you will notice a significant slow down in logging into ASG and managing the system anytime the caching of objects is required.  I got up to about 3400 users pre-fetched and at that point it would literally take 3 minutes to log into the WebAdmin, and we are running an Active-Active cluster on some pretty big hardware.

The support person told me that with a large AD environment like this that we should use SSO or groups in the groups section of Astaro that point back to AD.  Okay, I configured SSO, and the ASG was then added to the domain, but this did absolutely nothing to assist logging in.  I then proceeded to configure the EUP for only certain groups, and mapped those out in the group section t point to the respective AD groups.  This works fine, but I still have the users getting created on the Astaro side.  So I was then told to disable the "Auto Creation of Users" feature so the users would not get created, now the users can no longer login in again to the EUP.

So my big question is, are you supposed to be able to have users login to the EUP without having objects created for them on the Astaro side?


This thread was automatically locked due to age.
Parents
  • 0
    It sounds like you need more horsepower to do what you want.  With 5,000 users, on what platform are you running Astaro?

    In my experience, you can't have your own whitelist if there's no user defined in Astaro.  I haven't experimented with NOT allowing autocreation.  You've probably already thought about leaving auto-create off and limiting the pre-fetch to managers and some deparments.

    What about changing the inactivity timeout to 36000 so that you just have to sign on once a day?  I do that anyway and just have a short time-out requiring password on my desktop.

    Cheers - Bob
Reply
  • 0
    It sounds like you need more horsepower to do what you want.  With 5,000 users, on what platform are you running Astaro?

    In my experience, you can't have your own whitelist if there's no user defined in Astaro.  I haven't experimented with NOT allowing autocreation.  You've probably already thought about leaving auto-create off and limiting the pre-fetch to managers and some deparments.

    What about changing the inactivity timeout to 36000 so that you just have to sign on once a day?  I do that anyway and just have a short time-out requiring password on my desktop.

    Cheers - Bob
Children
  • 0 in reply to BAlfson
    Two servers running in Active-Active cluster, they are HP DL385 G1's, Dual XEON 2.6Ghz with 4GB or Ram.

    I think you answered my question with the statement about not having a whitelist if you do not have a user defined on Astaro. I do not want to prefetch at all, even if we only did staff and faculty, we are looking at 4000 accounts, and that caused too much of a slow down in the interface.  It effects more than just the login, anytime you click on the folder icon to choose a network, host, user, group etc, you are looking at the caching of all 4000 objects, so increasing the timeout, which we have done, only helps with the login portion.

    What I would love is a straight answer from Astaro on what type of hardware you need to implement a large scale user sync like this.  Surely we are not the only organization with 50,000 mailboxes, I hope.

    It sounds like you need more horsepower to do what you want.  With 5,000 users, on what platform are you running Astaro?

    In my experience, you can't have your own whitelist if there's no user defined in Astaro.  I haven't experimented with NOT allowing autocreation.  You've probably already thought about leaving auto-create off and limiting the pre-fetch to managers and some deparments.

    What about changing the inactivity timeout to 36000 so that you just have to sign on once a day?  I do that anyway and just have a short time-out requiring password on my desktop.

    Cheers - Bob
  • 0 in reply to BAlfson
    Just wanted to add a note, that even when we are experiencing the slowness in the interface, the "Resource Usage" on the dashboard, never goes far beyond 20% CPU and 30-40% memory utilization.

    It sounds like you need more horsepower to do what you want.  With 5,000 users, on what platform are you running Astaro?

    In my experience, you can't have your own whitelist if there's no user defined in Astaro.  I haven't experimented with NOT allowing autocreation.  You've probably already thought about leaving auto-create off and limiting the pre-fetch to managers and some deparments.

    What about changing the inactivity timeout to 36000 so that you just have to sign on once a day?  I do that anyway and just have a short time-out requiring password on my desktop.

    Cheers - Bob
  • 0 in reply to scmiles
    I think you should open a support ticket with Astaro.  If you have slowness when the CPU isn't over 20%, then there must be a bug.  It might be in a device driver or maybe code produced by Astaro.

    Are you certain that all of your devices are approved on the HCL including your drive controller?
  • 0 in reply to BAlfson
    We have a support case open.  Our hardware is approved.  You should be able to reproduce, if you want to see for yourself, just prefetch about 4000 users. After further testing we have narrowed it down to just these two issues, which are apparently due to the database design structure in Astaro.

    1)  With a large amount of objects, not just users, but in our case mostly users, when you first login it will take some time to cache everything, you will see the progress counter working.

    2)  The first time you access the object container folder for drag and drop, it will cache every object and this could take some time, as indicated by the progress counter and a message.

    The good news is that if you are using Fire Fox you will not have to cahce those objects again, for instance if you were just in an area where you were using drag and drop and you cached all the objects, and now you are in another area and initiate the drag and drop menu it will pop up in about 1-2 seconds.  Doing this in IE however, the pop up for the drag and drop menu takes around 20-30 seconds, even after the menu has been fully cached.

    We have made some design change suggestions to Astaro that should help environments with large amounts of objects with respect to the drag and drop menu.  One is that the caching of that menu should be done in the background along with an index of that table.  Also, rather than having the default filter for the drag and drop menu be "All Objects", it should be a search mode so you can type in a filter for objects and the "All" objects selection would be a secondary option.

    We are going to live with it for now, but it has changed our deployment plans for this version 7.x, there is no way we can allow for our student body to manage their own whitelists with End User Portals if it involves the creation of over 40,000 Astaro profiles to be created.

    It is clear that some design decisions were made for this version that negatively impact the large enterprise sized organizations, with respect to the removal of bulk management with whitelists, and now this design flaw when used with thousands of objects.

    There are ton of other awesome features however that make it definitely worth our while to implement now and use over our version 6.x boxes.

    I think you should open a support ticket with Astaro.  If you have slowness when the CPU isn't over 20%, then there must be a bug.  It might be in a device driver or maybe code produced by Astaro.

    Are you certain that all of your devices are approved on the HCL including your drive controller?
  • 0 in reply to scmiles
    Thanks very much for your posts above.  Let's hope Astaro quickly resolves the caching problems.

    Cheers - Bob