Understanding "Login never completed" events in EZproxy AutoLoginIP environments
Applies to
- EZproxy
Answer
Document Type: Technical Analysis
Audience: EZproxy administrators, IT support staff
Executive Summary
Administrators using AutoLoginIP authentication in OCLC EZproxy may observe "Login never completed" entries in their audit logs. This document explains why this behavior occurs, why it is unique to AutoLoginIP configurations, why many AutoLoginIP sessions do not exhibit this behavior, and when it requires attention versus when it represents normal operation.
Key Takeaway: "Login never completed" events are typically normal system behavior in specific environments (primarily NAT gateways serving multiple users) and indicate EZproxy's session cleanup mechanisms are working correctly. They do not represent authentication failures or security issues. Most AutoLoginIP sessions create single, successful sessions without this behavior.
Background
What is AutoLoginIP?
AutoLoginIP is an EZproxy authentication method that automatically authenticates users based on their source IP address without requiring credential entry. When configured in `config.txt`:
AutoLoginIP 192.168.1.100
AutoLoginIP 10.0.50.0-10.0.50.255
When a connection originates from a configured IP address, EZproxy immediately creates an authenticated session.
What Does "Login never completed" mean?
The "Login never completed" logout reason appears when:
1. A user successfully authenticates (Login.Success is logged)
2. An authenticated session is created
3. The session expires without ever requesting any proxied content
4. EZproxy's cleanup process terminates the unused session
Example audit log entry:
09:00:23 Login.Success 10.100.15.79 auto-10.100.15.79 s0R67NGv77lKaUr Groups Default
09:01:38 Logout auto-10.100.15.79 s0R67NGv77lKaUr Login never completed
What normal AutoLoginIP sessions look like
Most AutoLoginIP sessions create single, successful sessions:
00:01:14 Login.Success 10.50.22.42 auto-10.50.22.42 CrKu4FrfIgcMnT6 Groups Default
02:03:41 Logout auto-10.50.22.42 CrKu4FrfIgcMnT6 Expired
This session lasted approximately 2 hours, accessed proxied content successfully, and expired normally. This is the typical AutoLoginIP behavior.
Why this behavior is unique to AutoLoginIP
Authentication timing differences
The critical difference between AutoLoginIP and interactive authentication methods (Shibboleth, LDAP, CAS) is when the session is created:
AutoLoginIP flow:
1. Browser initiates TCP connection to EZproxy
2. EZproxy checks source IP address
3. Session created immediately (no user interaction required)
4. Browser may or may not use this connection
5. If unused, session times out as "Login never completed"
Interactive authentication flow:
1. Browser initiates TCP connection to EZproxy
2. User redirected to authentication provider
3. User provides credentials or SSO authentication occurs
4. User redirected back to EZproxy
5. Session created only after completed authentication flow
6. Speculative/abandoned connections close before reaching step 5
Why you don't see this with other authentication methods
Interactive authentication methods naturally filter out speculative and abandoned connections because the authentication process takes time. Browsers close unused connections before authentication completes. Only connections that complete the full authentication workflow create sessions.
AutoLoginIP creates sessions instantly, making every connection attempt—including those the browser or user immediately abandons—visible as authenticated sessions in the audit log.
Example from actual audit logs:
Shibboleth user sessions (note: zero "Login never completed" events):
00:24:04 Login.Success 68.147.25.71 user1@institution.edu z5P0sK3u0iw3vhB Shibboleth
02:30:41 Logout user1@institution.edu z5P0sK3u0iw3vhB Expired
01:00:32 Login.Success 172.219.83.214 user2@institution.edu 77PcfsgE9vmxe8A Shibboleth
03:20:45 Logout user2@institution.edu 77PcfsgE9vmxe8A Expired
All Shibboleth sessions show normal "Expired" logouts. The authentication delay filters out speculative connections before sessions are created.
Why some sessions don't show this behavior
The critical observation
Most AutoLoginIP sessions do NOT exhibit "Login never completed" behavior. Analysis of audit logs reveals that the majority of AutoLoginIP sessions create single, successful sessions that expire normally after hours of use.
Examples:
00:00:41 Login.Success 10.50.22.93 auto-10.50.22.93 pbHdrF093KjtY9a Groups Default
02:01:11 Logout auto-10.50.22.93 pbHdrF093KjtY9a Expired
00:01:14 Login.Success 10.50.22.42 auto-10.50.22.42 CrKu4FrfIgcMnT6 Groups Default
02:03:41 Logout auto-10.50.22.42 CrKu4FrfIgcMnT6 Expired
These sessions created only one session per access, lasted 1.5-2 hours, and successfully accessed proxied content.
Environment-specific patterns
Analysis reveals three distinct patterns:
Pattern 1: IPs that show ONLY single sessions
Example IPs: 10.50.22.93, 10.50.22.42, 10.50.22.55
What these represent:
- Individual user workstations
- Personal offices
- Direct IP assignments (not NAT)
Pattern 2: IPs that show ONLY multiple session bursts
Example IPs: 10.100.15.79, 10.100.20.118, 10.100.15.67
What these represent:
- Computer labs
- Shared workspaces with NAT
- Multiple users behind single IP
Pattern 3: IPs that show BOTH patterns
Example IPs: 10.150.18.22, 10.150.18.27
What these represent:
- Mixed-use facilities
- Spaces used by individuals sometimes, groups other times
Factors that prevent "Login never completed" behavior
1. Single user per IP address
When one person uses one workstation with one AutoLoginIP address, the browser's connection pooling works efficiently. The existing connection is reused for all requests, creating no additional sessions.
2. Off-peak access times
Time-of-day analysis reveals:
- Late night/early morning (00:00-06:00): Predominantly single sessions, minimal "never completed" events
- Peak hours (09:00-17:00): Mix of single and burst sessions
- Peak burst times (09:00, 13:00): Maximum burst activity from synchronized user behavior
3. Established browser connection tools
When a user already has an active EZproxy session, subsequent clicks reuse the existing authenticated connection. No need to establish new sessions.
4. Simple vs. complex database interfaces
Simple databases with minimal resources require one connection. Complex interfaces with multiple frames and parallel resource loading trigger browsers to open multiple connections.
5. Browser configuration
Conservative browser settings (older versions, corporate-managed profiles, mobile browsers) create fewer simultaneous connections. Aggressive settings (modern Chrome/Edge with pre-loading enabled) create more.
6. User behavior
Individual researchers accessing one database maintain single sessions. Classrooms of students clicking an instructor's link simultaneously create inevitable bursts.
Common causes of "Login never completed" events
1. Browser connection pooling and speculative connections
Modern browsers optimize performance by pre-opening 2-10 TCP connections simultaneously. All connections hit AutoLoginIP and create sessions, but only 1-2 are actually used for content.
Example:
09:52:55 Login.Success 10.100.15.67 auto-10.100.15.67 yxrl2YEq73Euf3X
09:52:56 Login.Success 10.100.15.67 auto-10.100.15.67 s5vdZGdzxKOBu1Q
[...8 more sessions in 5 seconds...]
09:53:00 Login.Success 10.100.15.67 auto-10.100.15.67 YL1MqYOF1a1TCwF
09:54:15 Logout auto-10.100.15.67 yxrl2YEq73Euf3X Login never completed
09:54:15 Logout auto-10.100.15.67 s5vdZGdzxKOBu1Q Login never completed
[...7 more "Login never completed"]
Session `YL1MqYOF1a1TCwF` successfully accessed content and continued beyond the cleanup window.
2. Multiple users behind NAT
In institutional environments, multiple users share a single public IP address. When they access EZproxy simultaneously (class starts, shift changes), all connections appear from the same AutoLoginIP address.
Example (shift change at 09:00):
09:00:23 Login.Success 10.100.15.79 [Session 1]
09:00:23 Login.Success 10.100.15.79 [Session 2]
09:00:23 Login.Success 10.100.15.79 [Session 3]
[...9 sessions within 20 seconds...]
09:01:38 Logout [7-8 "Login never completed"]
Contrast with single-user workstation:
09:00:41 Login.Success 10.50.22.93 [Single session]
11:01:11 Logout Expired
The difference is environmental: 10.100.15.79 serves multiple users; 10.50.22.93 serves one user.
3. User behavior patterns
Users may close tabs immediately, click the back button, open multiple databases but use only some, or accidentally click links. These behaviors only generate "Login never completed" events with AutoLoginIP because the session is created before the user abandons the connection.
4. Automated systems and monitoring
Health check systems, link checkers, or monitoring tools may create connections that are never used for actual content retrieval.
Example pattern:
[Repeats every 5 minutes, 24/7]
03:15:22 Login.Success 203.0.113.50 [SessionID]
03:15:52 Logout Login never completed
03:20:22 Login.Success 203.0.113.50 [SessionID]
03:20:52 Logout Login never completed
This constant pattern indicates automated activity, not human usage.
Understanding the environment-specific nature
Computer lab example: 10.100.15.79
Physical environment: 30-workstation computer lab, NAT gateway, scheduled classes
Observed behavior:
- Bursts at class start times (09:00, 13:00)
- 5-10 simultaneous sessions
- 60-80% "Login never completed"
Why burst pattern is inevitable: 30 users clicking within seconds, each browser opens 2-4 connections = 60-120 connection attempts. Most connections unused (browser parallelism).
Individual workstation example: 10.50.22.42
Physical environment: Single workstation, individual researcher's office
Observed behavior:
- Only single sessions
- Sessions last hours
- Always "Expired" logout
Why single session pattern is inevitable: One user, one browser. Browser connection pooling works efficiently.
Time-of-day analysis
| Time Period | Single Sessions | Burst Sessions | "Never Completed" Rate |
|-------------|----------------|----------------|------------------------|
| 00:00-06:00 | High | Low | 5-10% |
| 09:00-12:00 | Low | High | 25-35% |
| 17:00-00:00 | High | Low | 10-15% |
Peak burst times correlate with institutional schedules (class starts, shift changes).
When this behavior is normal
Expected scenarios
"Login never completed" events are normal and expected when:
1. Ratio is reasonable: 70-90% of AutoLoginIP sessions succeed overall, with 10-30% "never completed"
2. Time-based patterns: Bursts occur at predictable times (business hours, shift changes, class starts)
3. IP consistency: Specific IPs show consistent patterns (some always single, some always bursts)
4. Environment correlation: Burst patterns match known NAT/lab environments
Healthy pattern example
Academic institution (24-hour period):
- Total AutoLoginIP sessions: 450
- Successful sessions: 355 (79%)
- "Login never completed": 95 (21%)
- Sources: 15 NAT IPs (labs) + 80 individual workstations
Breakdown:
- Individual workstations: 320 sessions, 15 "never completed" (5%)
- NAT environments: 130 sessions, 80 "never completed" (62%)
Assessment: Normal. High "never completed" rate from NAT environments is expected; individual workstations show excellent performance.
When this behavior requires investigation
Warning signs
Investigate if you observe:
1. Excessive volume: >50% "never completed" across all IPs
2. Continuous pattern: 24/7 at steady rate from single IP
3. Single IP domination: One IP creating hundreds/thousands of sessions
4. Performance degradation: EZproxy response times increasing
5. Unknown IP addresses: AutoLoginIP addresses you don't recognize
6. Changed behavior: Previously normal IP suddenly shows excessive bursts
7. No successful sessions: IP shows only "never completed," never "Expired"
Comparing normal vs. concerning patterns
| Characteristic | Normal NAT Burst | Normal Single User | Concerning Pattern |
|---------------|------------------|-------------------|-------------------|
| Time pattern | Business hours, peaks | Variable, human | Constant 24/7 |
| Success rate | 30-40% successful | 95%+ successful | 0% successful |
| Variation | High | Moderate | None (robotic) |
| Weekend pattern | Reduced or absent | Reduced | Identical to weekdays |
Troubleshooting and analysis
Step 1: Identify the pattern
# Count "Login never completed" by IP
grep "Login never completed" ezproxy.log | awk '{print $3}' | sort | uniq -c | sort -rn
# Calculate success rate for specific IP
TOTAL=$(grep "Login.Success" ezproxy.log | grep "10.100.15.79" | wc -l)
INCOMPLETE=$(grep "Login never completed" ezproxy.log | grep "10.100.15.79" | wc -l)
echo "Success rate: $(echo "scale=2; ($TOTAL - $INCOMPLETE) / $TOTAL * 100" | bc)%"
# Identify IPs that never have successful sessions
grep "Login.Success" ezproxy.log | awk '{print $3}' | sort -u > all_ips.txt
grep "Expired" ezproxy.log | awk '{print $3}' | sort -u > expired_ips.txt
comm -23 all_ips.txt expired_ips.txt
Step 2: Categorize your AutoLoginIP addresses
Create an inventory:
| IP Address | Environment Type | Expected Pattern | Location |
|------------|-----------------|------------------|----------|
| 10.100.15.79 | NAT - Computer Lab | Burst (5-10) | Science Building, Room 203, 30 workstations |
| 10.50.22.42 | Individual | Single session | Faculty office |
| 10.150.25.121 | NAT - Conference | Variable | Meeting Room, 8 ports |
Step 3: Verify observed vs. expected
For each AutoLoginIP address, document expected behavior, measure actual behavior, compare, and flag discrepancies.
Step 4: Check for NAT environments
| Workstations Behind NAT | Expected Burst Size | Expected "Never Completed" Rate |
|------------------------|--------------------|---------------------------------|
| 1 (not NAT) | 1-2 sessions | 0-10% |
| 2-5 (small team) | 2-5 sessions | 20-40% |
| 10-20 (medium lab) | 5-15 sessions | 40-60% |
| 20-50 (large lab) | 10-30 sessions | 50-70% |
Step 5: Monitor performance impact
Check EZproxy CPU/memory usage, session counts against limits, and response times to verify the behavior isn't affecting operations.
Best practices and recommendations
1. Document your AutoLoginIP configuration
For each address, document:
- IP address or range
- Physical location
- Environment type (individual, NAT, lab)
- Number of workstations if NAT
- Expected usage patterns
- Contact person
Example:
# Science Building - Computer Lab Room 203
AutoLoginIP 10.100.15.79
Environment: NAT Gateway, 30 workstations
Expected Pattern: Burst at 09:00, 13:00, 15:00 (class times)
Expected "Never Completed": 40-70% during classes
Baseline: 5-30 simultaneous sessions during classes
2. Set appropriate session limits
Calculate total expected peak sessions:
- Individual workstations: 1 session each
- NAT environments: workstation count × 3
- Add 50% buffer
Example: 100 individual + 5 NAT (20 workstations each)
# = 100 + (5 × 20 × 3) = 400 sessions
# With buffer: 600
MaxSessions 600
MaxVirtualHosts 5000
3. Establish baseline metrics
Track daily:
- Total AutoLoginIP sessions
- Total "Login never completed"
- Overall ratio
- Top 10 IPs by volume
Sample baseline:
Total daily sessions: 450 (average)
"Login never completed": 95 (average)
Overall ratio: 21%
By environment:
- Individual workstations: 5% "never completed"
- NAT environments: 65% "never completed"
4. Implement monitoring and alerting
Set up alerts for:
- Any single IP >100 sessions per hour
- Overall ratio >40% for 24-hour period
- Unknown IPs appearing
- Any IP with 100% "never completed"
5. Regular audit log review
- Weekly: Review automated reports, check for unusual patterns (15-30 min)
- Monthly: Detailed trend analysis, update baselines (1-2 hours)
- Quarterly: Comprehensive audit, verify documentation (2-4 hours)
- Annual: Complete environment verification (half day)
6. Consider alternative authentication for problematic IPs
For environments with >80% "never completed," consider:
- Shibboleth/LDAP for computer labs
- Better user accountability
- Security/compliance requirements
Trade-offs:
- ✓ Reduces "never completed" visibility
- ✓ Better accountability
- ✗ Requires authentication step
- ✗ More complex configuration
Technical deep dive: Session timeout mechanics
Why 90 seconds?
EZproxy's session cleanup process terminates unused sessions after approximately 90 seconds. This timeout:
- Prevents accumulation of unused sessions
- Frees resources quickly
- Balances cleanup efficiency with user experience
- Allows browser connection pooling to stabilize
Session lifecycle comparison
Normal successful session:
T+0: Connection, AutoLoginIP authenticates
T+1s: Content request begins
T+2-120min: Active session proxying content
T+120min: Session expires
Logout: "Expired"
Abandoned session:
T+0: Connection, AutoLoginIP authenticates
T+1-89s: No content requests
T+90s: Cleanup terminates session
Logout: "Login never completed"
Comparison: AutoLoginIP vs. other authentication methods
| Method | Session Created When | "Never Completed" Visible? | Typical Rate |
|--------|---------------------|---------------------------|--------------|
| AutoLoginIP | Immediately | Yes | 10-30% (NAT) |
| Shibboleth | After IdP return | No | 0% (N/A) |
| LDAP | After credential verification | No | 0% (N/A) |
| CAS | After ticket validation | No | 0% (N/A) |
Key insight: "Login never completed" is not a deficiency—it's a consequence of AutoLoginIP's instant authentication meeting modern browser optimization.
Frequently Asked Questions
Q: Are "Login never completed" events security concerns?
A: No. These represent legitimate authenticated connections that weren't used. Not failed authentication, unauthorized access, or security breaches.
Q: Do these events consume resources?
A: Minimally. Sessions exist for only 90 seconds. EZproxy's cleanup efficiently terminates them.
Q: Should I remove AutoLoginIP addresses showing this behavior?
A: No, not based solely on "never completed" events. Only remove IPs that are no longer valid, showing suspicious 24/7 automated patterns, or confirmed compromised.
Q: Can I prevent this behavior?
A: Not entirely, and you shouldn't try. This is how modern browsers and NAT environments naturally operate. Focus on understanding your baseline and monitoring for abnormal patterns.
Q: How do I know if my ratio is too high?
A: Context matters. By environment:
- Individual workstations: 0-10% normal
- Small NAT (2-5 users): 20-40% normal
- Large NAT (20+ users): 60-80% normal during bursts
Overall 10-30% is normal for mixed environments. More important: understand your baseline and watch for deviations.
Q: Why do some IPs never show this behavior?
A: Single users per IP with efficient browser connection pooling create single, long-duration sessions. No burst activity possible.
Q: Should I switch to Shibboleth/LDAP to avoid this?
A: Only if you need user-level accountability, have security/compliance requirements, or can't use IP-based authentication. Don't switch just to hide "never completed" events—it's normal behavior, not a problem.
Conclusion
"Login never completed" events in EZproxy AutoLoginIP environments result from:
1. AutoLoginIP's instant authentication making connection-level behavior visible
2. Browser optimization (pre-opening connections)
3. Institutional NAT patterns (multiple users, synchronized access)
4. Legitimate user behavior (tab closing, navigation changes)
Key Takeaways
✅ Normal behavior - 10-30% "never completed" overall, higher (60-80%) in NAT environments during bursts
✅ Authentication succeeded - Not failed login attempts; proper cleanup
✅ Environment-specific - Different IPs show consistent patterns based on physical environment
✅ Most sessions succeed - Majority create single, long-duration sessions
✅ Monitor patterns, not ratios - Understand your baseline, watch for anomalies
When to take action
⚠️ Investigate:
- >50% "never completed" across all environments
- 100% "never completed" from any IP
- Constant 24/7 robotic patterns
- Performance degradation
- Sudden behavioral changes
✅ No action needed:
- Ratios align with environment types
- Patterns correlate with schedules
- Consistent expected behavior
- 70-90% overall success rate
Best practices summary
1. Document all AutoLoginIP addresses with environment details
2. Establish baseline metrics for each type
3. Implement automated monitoring
4. Review logs regularly
5. Educate staff on interpreting events
6. Focus on environment-specific analysis
7. Investigate deviations from baseline
Treat "Login never completed" as informational, not problematic. Understanding these patterns helps with capacity planning, identifying actual issues, and avoiding unnecessary configuration changes.
Additional information
Additional resources
- EZproxy Documentation: https://help-zh-hant.oclc.org/Library_Management/EZproxy
- AutoLoginIP Configuration: https://help-zh-hant.oclc.org/Library_Manage...es/AutoLoginIP
- OCLC Support: https://help-zh-hant.oclc.org/Contact_Us
When to contact support
Contact OCLC Support for:
- Sustained >50% "never completed" without explanation
- Performance degradation correlated with these events
- Assistance analyzing complex patterns
- Questions about your specific environment